Ubuntu Server’da Service Restart Policy

Ubuntu Server ortamlarında servislerin kesintisiz çalışması, kurumsal sistemlerin temel gereksinimlerinden biridir. Systemd servis yöneticisi, servislerin otomatik olarak yeniden başlatılmasına olanak tanıyan Restart policy mekanizması ile sistem yöneticilerine güçlü bir araç sunar. Bu politika, servislerin beklenmedik durumlarda hızlıca toparlanmasını sağlayarak downtime’ı minimize eder. Makalede, Ubuntu Server’da bu politikanın nasıl tanımlanacağını, seçeneklerini ve pratik uygulamalarını adım adım inceleyeceğiz. Bu bilgiler, sunucu altyapılarınızı daha dayanıklı hale getirmek için doğrudan kullanılabilir rehber niteliğindedir.

Systemd Servislerinde Restart Policy Temelleri

Ubuntu Server 18.04 ve sonrası sürümlerde varsayılan servis yöneticisi olan systemd, unit dosyalarında [Service] bölümünde Restart= direktifi ile servis yeniden başlatma politikasını belirler. Bu direktif, servis process’inin çıkış koduna, sinyaline veya timeout durumuna göre otomatik restart işlemini tetikler. Örneğin, servis normal çıkış yaparsa (exit code 0) restart olmazken, hata durumlarında (exit code 1-255 arası) yeniden başlatma devreye girer. Politika, sistemin stabilitesini artırırken, sonsuz döngüleri önlemek için RestartSec= ile gecikme süresi tanımlanabilir.

Restart policy’nin etkinleştirilmesi, servislerin yüksek erişilebilirlik gerektiren uygulamalarda kritik öneme sahiptir. Örneğin, web sunucusu Nginx veya veritabanı PostgreSQL gibi servislerde, ani çökmelerde manuel müdahale olmadan recovery sağlanır. Yapılandırma sırasında, Restart=always seçeneği her durumda yeniden başlatmayı garanti ederken, Restart=on-failure yalnızca başarısız çıkışlarda çalışır. Bu ayarlar, /etc/systemd/system/ dizini altında override dosyaları ile kalıcı hale getirilir ve systemctl daemon-reload komutu ile sisteme yüklenir.

Restart Policy Seçenekleri ve Yapılandırma Adımları

Restart= Direktif Seçenekleri

Systemd’de Restart= için dört ana seçenek bulunur: no (varsayılan, restart yok), on-success (başarılı çıkışta), on-failure (başarısız çıkışta), on-abnormal (sinyal veya timeout’ta) ve always (her durumda). Kurumsal ortamlarda on-failure önerilir, çünkü gereksiz restart’ları önler. Örnek unit dosyasında [Service] altında Restart=on-failure ekleyin, ardından RestartSec=5s ile 5 saniye gecikme tanımlayın. Bu, servis çöktüğünde hemen değil, kontrollü bir şekilde yeniden başlatılmasını sağlar. Test için systemctl restart servisadi komutunu kullanın ve journalctl -u servisadi ile logları izleyin.

RestartPreventExitStatus ve Limit Ayarları

RestartPreventExitStatus= ile belirli çıkış kodlarında restart’ı engelleyebilirsiniz, örneğin 2 (kasıtlı shutdown) için. Benzer şekilde RestartPreventSignal= ile SIGTERM gibi sinyalleri hariç tutun. Rate limiting için StartLimitIntervalSec=60s ve StartLimitBurst=3 ayarlayın; bu, 60 saniyede 3’ten fazla restart’ı bloke eder ve servis geçici olarak durdurulur. Uygulamada, /etc/systemd/system/myservice.service.d/override.conf dosyası oluşturun: [Service] Restart=on-failure StartLimitIntervalSec=10min StartLimitBurst=5. Sonra systemctl daemon-reload && systemctl restart myservice ile etkinleştirin. Bu ayarlar, kaynak tüketimini korurken güvenilirliği artırır.

Pratik Test ve İzleme Yöntemleri

Politikayı doğrulamak için kill -KILL $(pidof myservice) ile servisi zorla öldürün ve systemctl status myservice ile restart’ı gözlemleyin. Journalctl -f -u myservice ile gerçek zamanlı log takibi yapın. Performans için, birden fazla restart sonrası CPU ve bellek kullanımını top komutuyla izleyin. Bu adımlar, production öncesi testlerde zorunludur ve olası sorunları erken tespit eder.

Gelişmiş Uygulamalar ve En İyi Pratikler

Kurumsal Ubuntu Server’larda, containerized servisler (Docker, Podman) için systemd ile entegre restart policy kullanın. Örneğin, Docker daemon’unun unit dosyasında Restart=always tanımlayın ki konteynerler etkilenmesin. Cluster ortamlarında (Kubernetes öncesi), pacemaker ile kombine edin ancak systemd’i temel tutun. Güvenlik için, servisleri no-new-privs=yes ile kısıtlayın ve restart’ları SELinux/AppArmor politikalarıyla uyumlu hale getirin. Düzenli bakımda, systemctl edit servisadi ile interaktif override oluşturun; bu, orijinal dosyaları bozmadan özelleştirme sağlar.

En iyi pratiklerden biri, restart policy’yi servis ihtiyaçlarına göre özelleştirmektir: Kritik servisler için always, gelişim servisleri için on-abnormal. Monitöring araçları (Prometheus, Nagios) ile entegre ederek restart sayısını track edin. Güncellemelerde, apt upgrade sonrası systemctl restart ile policy’yi doğrulayın. Bu yaklaşımlar, uptime’ı %99.9 seviyelerine taşır ve operasyonel verimliliği artırır. Sonuç olarak, Ubuntu Server’da systemd restart policy’sini ustalıkla kullanmak, sistem yöneticilerinin proaktif yönetim becerisini güçlendirir ve iş sürekliliğini teminat altına alır.