Reload, restart ve daemon-reload arasındaki fark nedir; bakım sırasında hangisini ne zaman kullanmalısınız?

Bakım sırasında aynı işlemi sanıp farklı komut kullanmak neden sorun çıkarır?​

Sunucu yönetiminde en sık karışan konulardan biri, bir servisin yapılandırmasını yeniden yüklemek ile servisi tamamen yeniden başlatmak arasındaki farktır. Aynı şey gibi görünürler ama etkileri farklıdır. Yanlış komut kullanıldığında bağlantılar kesilebilir, eski ayarlar beklediğiniz gibi uygulanmayabilir ya da yalnızca systemd tarafı yenilenmiş olurken hizmetin kendisi değişmeden kalabilir.

Bu ayrımı doğru yapmak özellikle web sunucusu, reverse proxy, PHP-FPM, cache servisi ve benzeri uzun süre çalışan servislerde önemlidir. Çünkü her değişiklik tam yeniden başlatma gerektirmez; bazı değişiklikler kesinti yaratmadan uygulanabilir, bazıları ise ancak durdurup başlatarak güvenli şekilde yürür.

Üç kavramı ayrı düşünün​

reload genelde servisin kendi yapılandırmasını yeniden okumasını sağlar. Systemd tarafında systemctl reload, hizmetin servis içi konfigürasyonunu yenilemeye çalışır; bu, unit dosyasını değil servisin kendi ayarlarını hedefler. Apache’de graceful reload buna iyi bir örnektir: süreç mevcut istekleri bitirir, yapılandırmayı yeniden okur ve yeni nesil süreçlerle devam eder.

restart servisi durdurup tekrar başlatır. Bu, yalnızca ayarları yeniden okumakla kalmaz; proses durumunu, açık oturumları ve bazı geçici verileri de sıfırlar. Systemd dokümantasyonu restart’ın stop + start mantığıyla çalıştığını açıkça belirtir. Bu yüzden daha ağır bir işlemdir ama bazı değişikliklerde en temiz yoldur.

daemon-reload ise servisin kendisini değil, systemd’nin unit dosyalarını yeniden okuması içindir. Yani `` gibi tanımlar değiştiyse daemon-reload gerekir; ama Apache’nin httpd.conf dosyası değiştiyse daemon-reload tek başına yeterli değildir. Bu fark çok sık karıştırılır.

Hangi durumda hangisi uygundur?​

reload kullanın:

• Servis reload destekliyorsa
• Ayar değişikliği oturmuş prosesleri kapatmadan uygulanabiliyorsa
• Kısa kesinti istemiyorsanız
• Uygulama mantığı yeni konfigürasyonu canlı olarak okuyabiliyorsa

restart kullanın:

• Servis reload desteklemiyorsa
• Yeni sürüm veya kritik değişiklik prosesin yeniden doğmasını gerektiriyorsa
• Bellekte kalan eski durumun temizlenmesi gerekiyorsa
• Socket, PID, worker modeli veya benzeri yapı taşları değiştiyse

daemon-reload kullanın:

• Unit dosyasında değişiklik yaptıysanız
• Yeni environment, dependency, ExecStart veya restart politikası eklediyseniz
• Servis tanımını systemd’ye yeniden okutmak istiyorsanız

Bakım sırasında pratik karar sırası​

Önce değişikliğin nerede yapıldığına bakın: uygulama konfigürasyonu mu, systemd unit dosyası mı, yoksa yalnızca runtime davranışı mı? Eğer değişiklik servis dosyasındaysa önce daemon-reload gerekir. Eğer servis içi ayardaysa ve servis bunu destekliyorsa reload tercih edilir. Eğer servis reload desteklemiyor ya da davranışın tamamen sıfırlanması gerekiyorsa restart daha doğru seçimdir.

Bu sırayı uygulamak, gereksiz kesinti ve yanlış uygulama riskini azaltır. Örneğin Apache’de graceful restart, uygun durumlarda istekleri hemen kesmeden yeni konfigürasyona geçmeyi sağlar; buna karşılık systemctl restart servisi tamamen yeniden başlatır. Systemd tarafında da reload ile restart aynı şey değildir.

En yaygın hata nedir?​

En yaygın hata, “değişiklik yaptım, o halde restart atmam gerekir” varsayımıdır. Bu bazen gereksiz kesinti yaratır. Bir başka hata da unit dosyasını değiştirip sadece reload çalıştırmaktır; çünkü systemd unit dosyası değişikliklerini görmek için daemon-reload gerekir. Tersine, uygulama konfigürasyonu değiştiğinde daemon-reload yapıp servisin kendi ayarlarını yeniden okumasını beklemek de sorunu çözmez.

Kısa kural şu şekilde düşünülebilir: unit dosyası değiştiyse daemon-reload, servis içi ayar değiştiyse reload, süreç sıfırlanmalıysa restart. Bu ayrım doğru yapıldığında bakım işlemleri daha az riskli ve daha öngörülebilir olur.