Systemd Nedir ve Neden Önemlidir?
Systemd, modern Linux dağıtımlarının temel init sistemi ve servis yöneticisidir. Geleneksel SysVinit'e göre daha hızlı başlatma süresi, paralel servis yükleme ve kapsamlı bir bağımlılık yönetimi sunar. Bu özellikler sayesinde sunucularınız %40 daha hızlı ayağa kalkar ve hizmetlerin birbirine bağımlı olduğu karmaşık senaryolarda tutarlılık sağlar.
Systemd, unit adı verilen yapılandırma dosyalarıyla hizmetleri tanımlar. Bu dosyalar .service, .socket, .timer gibi farklı tiplerde olabilir ve her biri belirli bir görevi yerine getirir. Örneğin, bir web uygulamasını myapp.service dosyasıyla kontrol edebilir, bir veritabanı bağlantısını mysqld.service ile yönetebilirsiniz. Systemd ayrıca günlük (log) toplama, kaynak kısıtlama ve güvenlik profilleri gibi ek özelliklerle hizmetlerinizi bütünsel bir şekilde izler.
Systemd Unit Dosyalarının Temel Yapısı
Bir unit dosyası dört ana bölümden oluşur: [Unit], [Service], [Install] ve opsiyonel [Timer]. [Unit] kısmı hizmetin açıklamasını ve bağımlılıklarını tanımlar; [Service] kısmı çalıştırma komutlarını, yeniden başlatma politikalarını ve ortam değişkenlerini içerir; [Install] kısmı ise hizmetin hangi hedefe (runlevel) bağlanacağını belirtir.
Aşağıda basit bir example.service dosyasının örnek içeriği verilmiştir:
[Unit]
Description=Örnek Servis
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/example --run
Restart=on-failure
Environment=ENV=production
[Install]
WantedBy=multi-user.target
Bu dosyada After=network.target ifadesi, servisin ağ hizmetleri başlatıldıktan sonra çalışmasını sağlar. Restart=on-failure ise hizmet çökmesi durumunda otomatik yeniden başlatma politikasıdır. Böyle bir yapılandırma, özellikle AMD Ryzen VDS sunucular gibi yüksek performanslı ortamlar için kritik öneme sahiptir.
Systemd ile Servisleri Yönetme Komutları
Systemd'in en çok kullanılan komutları systemctl ve journalctl'dir. systemctl sayesinde hizmetleri başlatma, durdurma, yeniden yükleme ve durum sorgulama gibi işlemler tek bir satırda yapılabilir. Örneğin, bir servisi başlatmak için systemctl start myapp.service komutu yeterlidir.
Aşağıda yaygın kullanılan systemctl komutları listelenmiştir:
- start: Servisi başlatır.
- stop: Servisi durdurur.
- restart: Servisi yeniden başlatır.
- enable: Servisin sistem açılışında otomatik başlamasını sağlar.
- disable: Otomatik başlatmayı devre dışı bırakır.
- status: Servisin anlık durumunu ve loglarını gösterir.
Logları incelemek için ise journalctl -u myapp.service komutu kullanılır. Bu komut, servisin geçmişteki tüm çıktısını zaman damgasıyla birlikte sunar ve sorun giderme sürecinde büyük kolaylık sağlar.
Servis Başlatma ve Yeniden Başlatma Sorunlarını Çözme
Yeni bir unit dosyası eklediğinizde veya mevcut bir servisi değiştirdiğinizde systemctl daemon-reload komutunu çalıştırmanız gerekir. Bu komut, Systemd'in yapılandırma dosyalarını yeniden okumasını sağlar; aksi takdirde yapılan değişiklikler etkili olmaz.
Servislerin beklenmedik şekilde durması yaygın bir sorundur. Bunun en sık nedeni, eksik bağımlılık veya hatalı ExecStart komutudur. journalctl çıktısında “Failed to start” mesajını gördüğünüzde, ilgili unit dosyasındaki After ve Requires satırlarını kontrol edin. Ayrıca, RestartSec parametresiyle yeniden başlatma aralığını ayarlayarak servis çöküşlerinin sistem üzerindeki etkisini azaltabilirsiniz.
Özellikle web hosting paketleri sunan firmalar için, hizmetlerin kesintisiz çalışması müşteri memnuniyeti açısından kritiktir. Systemd'in sağladığı otomatik yeniden başlatma ve bağımlılık yönetimi, bu tür senaryolarda büyük avantaj sunar.
Kaynak Kısıtlama ve Güvenlik Ayarları
Systemd, hizmetlerin CPU, bellek ve I/O gibi kaynaklarını sınırlama imkanı tanır. MemoryLimit=, CPUQuota= ve IOWeight= gibi direktiflerle bir servisin ne kadar kaynak tüketebileceği tanımlanabilir. Örneğin, bir veritabanı servisi için MemoryLimit=1G ayarı, bellek sızıntılarını önleyerek sistem kararlılığını artırır.
Güvenlik açısından ise ProtectSystem=, PrivateTmp= ve NoNewPrivileges= gibi seçenekler izole bir çalışma ortamı sağlar. Bu ayarlar, hizmetin sadece gerekli dosyalara erişimini kısıtlayarak olası bir saldırı durumunda zararın yayılmasını engeller. Özellikle WAF güvenlik duvarı gibi ek güvenlik katmanlarıyla birlikte kullanıldığında, sisteminizin güvenlik profilini ciddi ölçüde güçlendirir.
Systemd Timer ile Zamanlanmış Görevler
Systemd, klasik cron yerine timer birimlerini kullanarak zamanlanmış görevleri yönetir. Timer birimleri, .timer uzantılı dosyalarla tanımlanır ve bir .service birimini tetikler. Bu yapı, görevlerin bağımlılıkları ve durum kontrolleriyle entegre bir şekilde çalışmasını sağlar.
Örneğin, günlük yedekleme görevini aşağıdaki gibi tanımlayabilirsiniz:
# backup.service
[Unit]
Description=Veritabanı yedekleme
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
# backup.timer
[Unit]
Description=Günlük yedekleme zamanlayıcısı
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
Bu timer, her gün saat 02:00'de backup.service'i çalıştırır. Persistent=true ayarı, sunucu kapalıyken kaçırılan bir çalışmayı sunucu açıldığında hemen yürütür, böylece kritik görevlerin atlanması önlenir.
Systemd ve Diğer Init Sistemleri Karşılaştırması
| Özellik | Systemd | SysVinit | Upstart |
|---|---|---|---|
| Başlatma Hızı | Paralel ve %40 daha hızlı | Sıralı, daha yavaş | Olay tabanlı, orta hız |
| Bağımlılık Yönetimi | Gelişmiş, otomatik | Manuel script | Kısmen otomatik |
| Log Yönetimi | journalctl entegrasyonu | Syslog | Syslog + ek |
| Kaynak Kısıtlama | CGroup tabanlı | Yok | Sınırlı |
| Zamanlanmış Görev | Timer birimleri | Cron | Upstart jobs |
Tablodan da görüldüğü gibi, Systemd modern sunucu ortamlarında hem performans hem de yönetilebilirlik açısından öne çıkar. Özellikle fiziksel sunucu (dedicated server) ve colocation hizmeti sunan altyapılarda, bu avantajlar hizmet kalitesini doğrudan etkiler.
Gerçek Dünya Senaryosu: WordPress Hosting’de Systemd Kullanımı
Bir WordPress hosting sağlayıcısı, müşterilerine yüksek kullanılabilirlik sunmak için PHP-FPM ve Nginx servislerini Systemd üzerinden yönetir. php-fpm.service ve nginx.service birim dosyaları, her iki hizmetin de bağımlılıklarını (örneğin, network.target) doğru tanımlayarak sunucu yeniden başlatıldığında sorunsuz bir şekilde ayağa kalkmasını sağlar.
Bu senaryoda, MemoryLimit=512M ve CPUQuota=50% gibi kısıtlamalar, tek bir müşterinin diğerlerini etkilemesini önler. Ayrıca, systemd‑tmpfiles‑setup.service ile geçici dosyaların periyodik temizlenmesi sağlanarak disk alanı yönetimi otomatikleştirilir. Sonuçta, müşteri memnuniyeti %70 artar ve destek maliyetleri azalır.
Sıkça Sorulan Sorular
Systemd ile bir servisi kalıcı olarak nasıl etkinleştiririm?
Servisi kalıcı olarak etkinleştirmek için systemctl enable servisadi.service komutunu kullanın. Bu komut, servis dosyasını multi-user.target.wants dizinine bir sembolik link ekleyerek sistem açılışında otomatik başlatılmasını sağlar.
Bir servis neden “failed” durumunda kalır ve nasıl düzeltilir?
“Failed” durumunun başlıca nedenleri eksik bağımlılık, hatalı ExecStart komutu veya yetersiz izinlerdir. journalctl -u servisadi.service ile logları inceleyin, After= ve Requires= satırlarını kontrol edin, gerekirse chmod ve chown izinlerini düzeltin.
Systemd timer ile cron arasındaki fark nedir?
Timer birimleri Systemd’in kendi içinde çalışır, bağımlılık yönetimi ve durum kontrolü sağlar. Cron ise ayrı bir daemon olarak çalışır ve Systemd’in sunduğu entegrasyon özelliklerinden yoksundur. Timer’lar ayrıca Persistent=true sayesinde kaçırılan görevleri otomatik olarak tamamlar.
Kaynak kısıtlamalarını nereden izleyebilirim?
Systemd’in systemd-cgtop ve systemd-analyze blame araçları, CPU, bellek ve I/O kullanımını gerçek zamanlı olarak gösterir. Ayrıca journalctl -u servisadi.service ile ilgili servis loglarından da kısıtlama ihlallerini tespit edebilirsiniz.
Sonuç ve Bir Sonraki Adım
Systemd, Linux sunucularında hizmet yönetimini daha hızlı, güvenli ve kontrol edilebilir bir hâle getirir. Bu makalede anlattığımız temel yapı taşları, unit dosyası oluşturma, servis kontrol komutları, kaynak kısıtlama ve timer kullanımı gibi konularla, sunucu performansınızı %70’e kadar artırabilirsiniz. Şimdi, kendi sunucunuzda bir .service dosyası oluşturup systemctl daemon-reload komutunu çalıştırarak uygulamaya başlayın. Eğer daha yüksek performans ve ölçeklenebilirlik arıyorsanız, Intel i9 VDS sunucular ile kombinleyerek tam bir altyapı çözümüne geçiş yapabilirsiniz.
