Systemd Nedir ve Neden Kullanmalıyız?
Linux dünyasında systemd, init sisteminin yerini alarak hizmetlerin (servislerin) başlatılmasını, durdurulmasını ve izlenmesini tek bir çatı altında toplar. Geleneksel SysVinit’e göre %40 daha hızlı başlatma süresi sunar; bu da özellikle AMD Ryzen VDS sunucular gibi yüksek performanslı ortamlarda kritik bir avantajdır. Systemd, bağımlılık ağacını otomatik çözer, paralel başlatma yapar ve bir servis çökse bile diğerlerini etkilemeden izole eder.
Birçok yaygın hata, servislerin yanlış sırayla başlatılması ya da bağımlılıkların eksik tanımlanmasıdır. Bu hatalar, sistemin yavaşlamasına, hizmet kesintilerine ve hatta veri kaybına yol açabilir. Örneğin, veritabanı servisi web sunucusundan önce başlamazsa, web uygulaması hatalar üretir ve bu da müşteri memnuniyetsizliğine dönüşür. Systemd’in After= ve Requires= gibi direktifleri, bu tür senaryoları önceden tanımlayarak maliyetli kesintileri engeller.
Systemd Unit Dosyaları Nasıl Oluşturulur?
Systemd, her hizmeti bir “unit” dosyasıyla temsil eder. En yaygın tip .service dosyalarıdır ve /etc/systemd/system/ dizininde bulunur. Bir unit dosyası üç ana bölüme ayrılır: [Unit], [Service] ve [Install]. [Unit] bölümü, hizmetin açıklamasını ve bağımlılıklarını tanımlar; [Service] kısmı çalıştırılacak komutu, çalışma dizinini ve yeniden başlatma politikasını içerir; [Install] ise hizmetin hangi hedefe (target) bağlanacağını belirler.
Örnek bir Nginx servis tanımı şu şekildedir:
[Unit]
Description=Nginx HTTP Server
After=network.target
[Service]
Type=forking
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/usr/sbin/nginx -s quit
PIDFile=/run/nginx.pid
Restart=on-failure
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target
Bu dosyayı /etc/systemd/system/nginx.service konumuna kaydedip systemctl daemon-reload komutuyla systemd’ye bildirmeniz yeterlidir. Ardından systemctl enable nginx ile otomatik başlatmayı ayarlayabilirsiniz.
Servisleri Yönetmek: Başlatma, Durdurma ve İzleme
Systemd servislerini kontrol etmek için systemctl komutu kullanılır. En sık kullanılan alt komutlar şunlardır:
systemctl start <service>– Servisi anında başlatır.systemctl stop <service>– Servisi durdurur.systemctl restart <service>– Servisi yeniden başlatır.systemctl reload <service>– Konfigürasyon değişikliklerini yeniden yükler (servisi durdurmaz).systemctl status <service>– Servisin mevcut durumu, son günlük girdileri ve hata kodlarını gösterir.
Özellikle systemctl status çıktısı, hatalı bir servisin neden çöküşe uğradığını anlamak için kritik bilgiler içerir. Günlük (log) verileri journalctl -u <service> komutuyla erişilir; burada zaman damgaları, hata seviyeleri ve stack trace’ler bulunur. Bu sayede web hosting paketleri üzerinde çalışan bir PHP-FPM servisi anlık olarak izlenebilir ve sorunlar anında tespit edilebilir.
Bağımlılık ve Hedef (Target) Yönetimi
Systemd, servisler arasındaki bağımlılıkları After=, Before=, Requires= ve Wants= anahtarlarıyla tanımlar. After= servisin diğer bir servisten sonra başlamasını zorunlu kılar, ancak bağımlılığı zorunlu kılmaz; Requires= ise zorunlu bağımlılık ekler. Bu iki direktifin kombinasyonu, hizmetlerin doğru sırayla ve eksiksiz olarak başlatılmasını sağlar.
Target kavramı ise bir grup servisin aynı anda yönetilmesini sağlar. Örneğin multi-user.target tipik bir çok kullanıcı ortamını temsil ederken, graphical.target masaüstü ortamı için kullanılır. Kendi özel hedefinizi oluşturmak, birden fazla mikroservisi tek bir komutla başlatıp durdurmanıza imkan tanır. Bu, Intel i9 VDS sunucular gibi yüksek kapasiteli ortamlarda bakım pencerelerini kısaltır.
Günlük (Journal) Yönetimi ve Log Analizi
Systemd’nin yerleşik günlük sistemi journald, sistem ve uygulama loglarını tek bir veri tabanında toplar. Loglar binary formatta saklandığı için journalctl komutuyla filtreleme, arama ve zaman dilimi bazlı görüntüleme yapılabilir. Örneğin, son 1 saat içinde Nginx ile ilgili hataları görmek için:
journalctl -u nginx -p err --since "1 hour ago"Log rotasyonu ve kalıcı saklama /etc/systemd/journald.conf dosyasında Storage=persistent ayarıyla etkinleştirilebilir. Böylece sunucu yeniden başlatılsa bile geçmiş loglar korunur, bu da WAF güvenlik duvarı yapılandırmalarının denetlenmesinde büyük fayda sağlar.
Servis Güvenliği: İzolasyon ve Kısıtlama
Systemd, servisleri izole etmek için PrivateTmp, ProtectSystem, ReadOnlyDirectories ve CapabilityBoundingSet gibi güvenlik seçenekleri sunar. Örneğin, bir MySQL servisini sadece okunabilir bir dosya sisteminde çalıştırmak için:
[Service]
...
ProtectSystem=full
ReadOnlyDirectories=/
Bu ayarlar, bir saldırganın servisin dosya sistemine zarar vermesini engeller ve zero‑day saldırı riskini azaltır. Ayrıca, LimitNOFILE ve LimitNPROC gibi kaynak sınırları, hizmetin aşırı kaynak tüketimini önleyerek sunucunun stabilitesini korur.
Performans ve Ölçeklenebilirlik: Systemd ile Yük Dengeleme
Systemd, bir hizmetin birden fazla örneğini (instance) yönetmek için şablon unit dosyaları (.service@.service) sunar. Örneğin, bir Node.js uygulamasını her bir CPU çekirdeği için ayrı bir instance olarak çalıştırmak, CPU kullanımını %30‑40 artırabilir. Şablon dosyası şu şekilde tanımlanır:
[Unit]
Description=Node.js uygulama %i
After=network.target
[Service]
ExecStart=/usr/bin/node /opt/app/app.js --instance %i
Restart=on-failure
User=node
Group=node
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
Bu dosyayı nodeapp@.service olarak kaydedip systemctl enable nodeapp@1, systemctl enable nodeapp@2 gibi komutlarla birden fazla örnek etkinleştirilebilir. Böyle bir yapı, e-ticaret hosting ortamlarında yüksek trafik dalgalanmalarını sorunsuz karşılamaya yardımcı olur.
Systemd ile Yedekleme ve Geri Dönüş Stratejileri
Servislerin durumu, konfigürasyon dosyaları ve veri dizinleri yedeklenirken systemd’nin ExecStopPost ve ExecStartPost komutları kullanılabilir. Örneğin, bir PostgreSQL servisi durmadan önce anlık yedek alıp, yeniden başlatıldıktan sonra yedekleme dosyasını temizlemek için:
[Service]
...
ExecStopPost=/usr/local/bin/pg_backup.sh
ExecStartPost=/usr/local/bin/cleanup_backup.sh
Bu yaklaşımla, yedekleme süreci hizmet kesintisi olmadan yürütülür; böylece fiziksel sunucu (dedicated server) ortamlarında veri kaybı riski en aza iner.
Sıkça Sorulan Sorular
Systemd yerine SysVinit kullanmanın avantajları nelerdir?
SysVinit, basit yapısı sayesinde bazı çok eski sistemlerde tercih edilebilir, ancak paralel başlatma, bağımlılık yönetimi ve journal entegrasyonu gibi modern özellikler eksiktir. Systemd, bu eksikleri kapatarak %40 daha hızlı boot süresi ve daha düşük bakım maliyeti sağlar.
Bir servis sürekli olarak yeniden başlatılıyor, ne yapmalıyım?
Öncelikle systemctl status ve journalctl -u <service> ile hata mesajlarını inceleyin. Çoğu zaman eksik bağımlılık (Requires=), yetersiz kaynak limiti (LimitNOFILE) veya hatalı konfigürasyon (yanlış ExecStart) bu duruma yol açar. Sorunu tespit edip unit dosyasını düzeltmek gerekir.
Systemd’nin journal dosyaları ne kadar yer kaplar ve nasıl temizlenir?
Varsayılan olarak journal, 10% RAM ve 100 MB disk alanı sınırıyla çalışır. journalctl --vacuum-size=50M komutu en eski kayıtları silerek boyutu 50 MB’a düşürür. Ayrıca SystemMaxUse ve RuntimeMaxUse ayarları /etc/systemd/journald.conf içinde yapılandırılabilir.
Systemd bir servisi “masked” (maskeleme) durumu ne anlama gelir?
Maskeleme, bir servisin tüm bağlantılarını /dev/null’a yönlendirir; böylece systemctl start komutu bile servisi başlatamaz. Bu, kritik olmayan veya güvenlik riski taşıyan bir servisi tamamen devre dışı bırakmak için kullanılır. Maskelemek için systemctl mask <service> komutu yeterlidir.
Sonuç ve Önerilen Sonraki Adım
Systemd, sadece bir init sistemi değil, aynı zamanda hizmet yönetimi, günlük takibi, güvenlik izolasyonu ve ölçeklenebilirlik sağlayan kapsamlı bir platformdur. Makalemizde gördüğünüz gibi unit dosyaları oluşturmak, bağımlılıkları doğru tanımlamak, journal’i etkili kullanmak ve güvenlik sınırlamaları eklemek, sunucunuzun stabilitesini ve performansını doğrudan artırır. Şimdi, kendi sunucunuzda bir test servisi oluşturarak bu adımları uygulayın; bir sonraki adımda ise şablon unit dosyalarıyla çoklu örnek yönetimini deneyimleyin. Böylece, colocation hizmeti aldığınız altyapıda bile yüksek erişilebilirlik ve düşük gecikme elde edersiniz.
