Systemd ile Linux Servis Yönetimi: Unit Dosyaları, Bağımlılıklar ve Hayat Kurtaran Komutlar

Linux sistem yöneticisi olarak çalışmaya başladığınızda, arka planda sürekli çalışan servislerin (daemons) nasıl yönetildiğini anlamak kritik bir eşiktir. Geçmişte System V init veya Upstart gibi yapılar kullanılırken, modern dağıtımların neredeyse tamamı artık systemd kullanıyor. Bazı çevrelerde tartışmalı bir konu olsa da systemd; servis yönetimini, bağımlılıkları ve log mekanizmalarını tek bir çatı altında toplayan güçlü bir ekosistemdir.

Bu yazıda, systemd’nin çalışma mantığını, kendi servis unit dosyalarımızı nasıl yazacağımızı ve günlük operasyonlarda işimizi hızlandıracak pratik komutları ele alacağız.

Systemd Nedir ve Neden Önemlidir?

Systemd, Linux işletim sistemleri için bir sistem ve servis yöneticisidir. PID 1 olarak başlar, yani çekirdekten sonra sistemde ayağa kalkan ilk süreçtir ve diğer tüm süreçlerin atasıdır. Sadece servis başlatıp durdurmakla kalmaz; dosya sistemi mount işlemlerini, ağ yapılandırmalarını, soket yönetimini ve zamanlanmış görevleri de denetler.

Bir sistem yöneticisi için systemd’yi anlamak, sunucu açılış süresini (boot time) optimize etmek, çöken servisleri otomatik olarak yeniden başlatmak ve servisler arası bağımlılık kilitlerini çözmek adına şarttır.

Temel `systemctl` Komutları ve Günlük Kullanım

Servis yönetimi denildiğinde akla ilk gelen komut systemctl’dir. Günlük işlerimizde en çok kullandığımız temel komutları hatırlayalım:

# Bir servisin durumunu kontrol etme
systemctl status nginx

# Bir servisi başlatma
systemctl start nginx

# Bir servisi durdurma
systemctl stop nginx

# Bir servisi yeniden başlatma
systemctl restart nginx

# Yapılandırma dosyalarındaki değişiklikleri servisi durdurmadan yükleme
systemctl reload nginx

# Servisin sistem açılışında otomatik başlamasını sağlama
systemctl enable nginx

# Otomatik başlamayı iptal etme
systemctl disable nginx

Maskeleme (Masking) Kavramı

Bazen bir servisin sadece devre dışı kalması yetmez; başka bir bağımlılık tarafından yanlışlıkla tetiklenmesini de engellemek isteyebilirsiniz. Bu durumda mask komutu devreye girer:

systemctl mask bluetooth

Bu komut, servisin /dev/null’a sembolik bağını oluşturarak başlatılmasını tamamen engeller. Eski haline getirmek için ise systemctl unmask bluetooth komutunu kullanabilirsiniz.

Unit Dosyaları Anatomisi: Kendi Servisimizi Yazmak

Systemd’nin kalbi Unit dosyalarıdır. Servisler, socket’ler, mount noktaları ve timer’lar birer unit’tir. Biz genellikle .service uzantılı dosyalarla ilgileniriz.

Özel bir Python web uygulamamız olduğunu ve bunu bir systemd servisi olarak arkada sürekli çalışır hale getirmek istediğimizi varsayalım.

Unit dosyaları genellikle iki ana dizinde yer alır:

Sistem genelindeki varsayılanlar: /lib/systemd/system/ veya /usr/lib/systemd/system/
Yerel ve özelleştirilmiş dosyalar: /etc/systemd/system/

Biz kendi servis çalışmamızı /etc/systemd/system/ dizini altında yapacağız.

Adım Adım Servis Dosyası Oluşturma

/etc/systemd/system/myapp.service adında bir dosya oluşturalım:

[Unit]
Description=Python Flask Web Uygulamasi
After=network.target mysql.service

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/python3 /var/www/myapp/app.py
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Bu dosyadaki parametreleri yakından inceleyelim:

[Unit] Bölümü:
- Description: Servis hakkında kısa bir açıklama. systemctl status çıktısında görünür.
- After: Bu servisin hangi servislerden sonra başlatılması gerektiğini belirtir. Örneğimizde ağ (network.target) ve MySQL veritabanı ayağa kalktıktan sonra bu servis çalışacaktır.
[Service] Bölümü:
- Type: Sürecin nasıl başlatılacağını söyler. simple en yaygın olanıdır; ExecStart ile verilen komut doğrudan ana süreç olur.
- User ve Group: Servisin hangi yetkilerle çalışacağını belirler. Güvenlik açısından asla root kullanmamalısınız.
- WorkingDirectory: Komutun çalıştırılacağı dizin.
- ExecStart: Servisi başlatan tam komut satırı.
- Restart: Servis çöktüğünde ne yapılacağını belirler. on-failure seçeneği, uygulama hata kodlarıyla (0 dışında) sonlandığında yeniden başlatılmasını sağlar.
- RestartSec: Yeniden başlatma denemesi yapmadan önce beklenecek süre.
- StandardOutput ve StandardError: Logların nereye yazılacağını belirtir. journal seçeneği logları systemd journal mekanizmasına yönlendirir.
[Install] Bölümü:
- WantedBy: Servisin hangi target (hedef) seviyesine bağlandığını gösterir. multi-user.target, klasik runlevel 3 (multi-user, GUI olmayan sunucu modu) anlamına gelir.

Servisi Sisteme Tanıtma ve Çalıştırma

Yeni bir unit dosyası oluşturduğumuzda veya mevcut bir dosyayı değiştirdiğimizde, systemd’nin bu değişiklikten haberdar olması için daemon’ı yeniden yüklememiz gerekir:

systemctl daemon-reload

Ardından servisimizi etkinleştirip başlatalım:

systemctl enable --now myapp.service

(—now parametresi hem enable hem de start işlemlerini tek komutta yapar.)

Bağımlılık Yönetimi (Dependencies) ve Target Kavramı

Systemd, klasik runlevel kavramını Target birimleri ile değiştirmiştir. Target’lar, aslında diğer unit’lerin gruplandırılmış halleridir.

En sık karşılaşılan target’lar şunlardır:

poweroff.target: Sistemi kapatır.
rescue.target: Tek kullanıcı modu (kurtarma modu).
multi-user.target: Çok kullanıcılı, komut satırı tabanlı ağ hizmetleri aktif mod.
graphical.target: Grafik arayüzün de dahil olduğu mod.

Mevcut varsayılan target’ınızı görmek için:

systemctl get-default

Bir servisin bağımlılık zincirini görselleştirmek, özellikle karmaşık mimarilerde sorun giderirken hayat kurtarır:

systemctl list-dependencies myapp.service

Journalctl ile Log Analizi

Systemd, logları journald servisi aracılığıyla ikili (binary) formatta toplar. Geleneksel /var/log/syslog veya /var/log/messages dosyalarının aksine, journald hızlı arama ve filtreleme imkanı sunar.

Kendi yazdığımız myapp.service servisinin loglarını anlık olarak takip etmek için:

journalctl -u myapp.service -f

Sadece son 1 saat içinde üretilen hatalı logları görmek istiyorsanız:

journalctl -u myapp.service --since "1 hour ago" -p err

Disk üzerindeki journal loglarının kapladığı alanı sınırlamak (örneğin 500MB ile sınırlandırmak) için /etc/systemd/journald.conf dosyasındaki SystemMaxUse=500M parametresini aktif edebilir ve servisi yeniden başlatabilirsiniz:

systemctl restart systemd-journald

Sık Yapılan Hatalar ve İpuçları

Daemon-reload Unutmak: /etc/systemd/system/ altındaki bir dosyayı güncelledikten sonra systemctl daemon-reload komutunu çalıştırmazsanız, systemd eski yapılandırmayı çalıştırmaya devam eder.
Mutlak Yol (Absolute Path) Kullanmamak: Servis dosyalarındaki ExecStart parametresinde komutların ve betiklerin tam yollarını (absolute path) kullanmalısınız (Örn: /usr/bin/python3 yerine sadece python3 yazmak PATH problemleri nedeniyle başarısız olabilir).
Yetki Kısıtlamaları: Uygulamalarınızı her zaman en az yetki prensibine (Principle of Least Privilege) uygun kullanıcılarla çalıştırın.

Sonuç

Systemd, modern Linux sistem yönetiminin omurgasıdır. Sadece hazır servisleri yönetmek değil, kendi özel servislerimizi yazabilmek, bağımlılıkları doğru kurgulayabilmek ve journalctl ile etkili log analizi yapabilmek her sistem yöneticisinin ve DevOps mühendisinin sahip olması gereken temel becerilerdir.

Doğru yapılandırılmış bir systemd servisi, sunucunuzun kararlılığını artırır ve olası kesintilerde manuel müdahale ihtiyacını en aza indirir.

Bu yazı Gemini ile otomatik oluşturulmuştur.