systemd ile Linux servisleri nasıl yönetilir

systemd ve birim (unit) kavramı

systemd, modern Linux dağıtımlarının çoğunda sistem açılışını ve servis yaşam döngüsünü yöneten başlatma sistemidir. Her yönetilen şey bir "birim" (unit) olarak tanımlanır: servisler (.service), bağlama noktaları (.mount), zamanlayıcılar (.timer), soketler (.socket) ve hedefler (.target). Servis yönetimi, çoğunlukla servis birimleriyle çalışmak demektir.

Eski başlatma betiklerinden farkı, bağımlılıkları ve sıralamayı açıkça tanımlamasıdır. Bir servis hangi servisten sonra başlamalı, hangisine ihtiyaç duyuyor, çökerse yeniden başlatılsın mı gibi kurallar birim dosyasında yazılır. Sistemin hangi hedefe doğru açılacağı da (grafik arayüzlü ya da yalnızca komut satırı) bir hedef birimiyle belirlenir.

Her işi systemctl komutu ile yaparsınız. Günlük kayıtları ise journalctl ile okursunuz. İkisini birlikte kullanmak, "servis neden açılmadı" sorusunu yanıtlamak için temel yoldur.

Servisleri başlatma, durdurma ve kalıcı yapma

Günlük kullanımın çekirdeği şu komutlardır:

• systemctl status nginx : servisin çalışıp çalışmadığını, son kayıt satırlarını ve ana süreç bilgisini gösterir.
• systemctl start nginx ve systemctl stop nginx : servisi o an başlatır ya da durdurur, yeniden başlatmada geçerli olmaz.
• systemctl restart nginx : durdurup yeniden başlatır; yapılandırmayı yeniden okuyabilen servislerde systemctl reload kesinti yaratmadan yeni ayarı uygular.
• systemctl enable nginx ve systemctl disable nginx : servisin açılışta başlamasını sağlar ya da kaldırır; enable --now birlikte hem başlatır hem kalıcı yapar.

En sık karışan nokta, çalışmakla etkin olmak arasındaki farktır. Bir servis start ile çalışıyor olabilir ama enable edilmemişse yeniden başlatmadan sonra gelmez. Tersi de mümkündür: enable edilmiş ama başlatılmamış bir servis hâlâ kapalıdır. systemctl is-active ve systemctl is-enabled bu iki durumu ayrı ayrı sorgular ve betiklerde işe yarar.

Bir servisin yanlışlıkla başlatılmasını tümden engellemek için systemctl mask kullanılır: birimi boş cihaza bağlayarak elle bile başlatılamaz hale getirir. Geri almak için unmask komutu çalıştırılır.

Durum izleme ve sorun giderme

Bir servis ayağa kalkmıyorsa önce systemctl status çıktısına bakın: son kayıt satırları ve çıkış kodu çoğu zaman nedeni söyler. Daha fazla ayrıntı için journalctl -u nginx komutuyla yalnızca o birimin kayıtlarını görün; -f canlı takip, -b yalnızca mevcut açılıştan itibarki kayıtları, -p err ise yalnızca hata seviyesindeki mesajları verir.

Tipik hata kalıpları ve bakılacak yerler: • Yapılandırma dosyası hatalı: servis başlar başlamaz çıkar, kayıtta sözdizimi satırı bulunur. • Port kullanımda: başka bir süreç aynı portu tutuyordur, ss -tlnp ile görülür. • İzin ve SELinux: servis dosyaya erişemiyordur; denetim kayıtlarına bakmak gerekir. • Bağımlılık: gereken servis ya da bağlama hazır değildir; systemctl list-dependencies ilişkiyi gösterir.

Sistem genelinde başarısız birimleri listelemek için systemctl --failed çok kullanışlıdır. Açılışın nerede yavaşladığını görmek için ise systemd-analyze blame çıktısı en uzun süren birimleri sıralar. Bu iki komutla bir sunucunun genel sağlığına hızlı bakış yapılabilir.

Kendi servis birim dosyanızı yazmak

Örneğin bir uygulamayı sunucuda arka plan servisi olarak çalıştırmak istiyorsunuz. Birim dosyası /etc/systemd/system dizinine konur; adı uygulama.service olsun. Şu bölümleri içerir:

[Unit] Description=Örnek uygulama After=network.target

[Service] ExecStart=/usr/local/bin/uygulama Restart=on-failure User=uygulama

[Install] WantedBy=multi-user.target

Unit bölümü açıklama ve sıralama bilgisini taşır. Service bölümü hangi komutun, hangi kullanıcıyla çalışacağını ve çökerse ne yapılacağını söyler. Install bölümü enable edildiğinde servisin hangi hedefe bağlanacağını belirler.

Dosyayı yazdıktan sonra systemd'ye değişikliği bildirmeniz gerekir: systemctl daemon-reload. Sonra systemctl enable --now uygulama komutuyla başlatıp kalıcı yapın ve status ile doğrulayın. Servisi kök yetkileriyle çalıştırmak yerine özel bir kullanıcı tanımlamak, güvenlik açısından iyi alışkanlıktır.

Paket ile gelen birim dosyalarını doğrudan düzenlemeyin; güncelleme sırasında ezilirler. systemctl edit uygulama komutu, asıl dosyayı korurken üstüne yazan bir ek yapılandırma (drop-in) oluşturur.

Hedefler, zamanlayıcılar ve açılış davranışı

systemd hedefleri eski çalışma seviyelerinin yerini alır. multi-user.target grafik arayüzsüz çok kullanıcılı kipi, graphical.target grafik arayüzlü kipi temsil eder. Varsayılan hedefi systemctl get-default ile görür, systemctl set-default ile değiştirirsiniz. Sorun giderme için rescue.target ve emergency.target gibi kurtarma hedefleri de vardır; sistemi bu hedeflerden birine geçirmek için systemctl isolate kullanılır.

Zamanlanmış işler için cron'a alternatif olarak systemd zamanlayıcıları (.timer) vardır. Bir zamanlayıcı birimi, aynı adı taşıyan servis birimini belirlenen takvimde tetikler. Avantajı, çıktının journalctl ile toplanması ve bağımlılık, kaynak sınırı gibi servis özelliklerinden yararlanabilmesidir. systemctl list-timers etkin zamanlayıcıları ve bir sonraki çalışma anlarını gösterir.

Kaynak kontrolü de birim düzeyindedir. Servis dosyasına bellek ve işlemci sınırları yazarak tek bir servisin sunucuyu tüketmesini engelleyebilirsiniz; ayrıntı için ilgili man sayfasına başvurun.

Sık hatalar ve kontrol listesi

En sık hata, birim dosyasını değiştirip daemon-reload çalıştırmamaktır; systemd eski tanımla devam eder. Diğeri start ile enable'ı karıştırmaktır. Üçüncüsü, servis hatasını yalnızca status satırlarına bakarak aramaktır; asıl neden çoğu zaman journalctl çıktısındadır. Dördüncü hata paket birim dosyasını düzenleyip güncellemede kaybetmektir.

Kontrol listesi: • Servis çalışıyor mu (is-active) ve açılışta gelecek mi (is-enabled)? • Birim dosyası değiştiyse daemon-reload yapıldı mı? • journalctl -u kayıtlarında hata satırı var mı? • Bağımlılık ve port çakışması kontrol edildi mi? • Yeniden başlatma sonrasında servis beklendiği gibi geliyor mu?

Sınavlarda ve üretimde aynı sıra geçerlidir: kur, başlat, kalıcı yap, yeniden başlatarak doğrula.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

RHCSA Sertifikasyon Hazırlık programının Süreç, Servis ve Zamanlama modülü systemd servis yönetimini ve zamanlamayı bir arada işler. Linux Foundation Certified System Administrator (LFCS) Hazırlık programında Servis ve Süreç Yönetimi modülü benzer içeriği başka bir sertifika yolu bakışıyla sunar. Bu programlar Linux sunucu işletmesinden sorumlu olacak ya da bu görevi devralacak BT ekipleri için uygundur.