Ubuntu Server’da Systemd Service Restart Policy

Ubuntu Server ortamlarında systemd servis yöneticisi, sistem stabilitesini ve servis sürekliliğini sağlamak için kritik bir rol oynar. Özellikle restart policy mekanizması, servislerin beklenmedik durumlarda otomatik olarak yeniden başlatılmasını düzenleyerek kesintisiz operasyonları destekler. Bu politika, servis birim dosyalarında tanımlanır ve failure, success veya diğer olaylara göre davranışı belirler. Makalede, bu politikanın temel prensiplerini, pratik yapılandırma adımlarını ve örnek uygulamaları ele alarak, sistem yöneticilerine somut rehberlik sunacağız. Bu sayede, üretim ortamlarında güvenilir servis yönetimi sağlayabilirsiniz.

Systemd Restart Politikalarının Temel Yapısı

Systemd’de restart policy, servislerin ne zaman yeniden başlatılacağını belirleyen bir dizi seçeneği kapsar. Temel olarak, Restart= direktifi ile ayarlanır ve no, on-success, on-failure, on-abnormal, on-abort, on-watchdog veya always gibi değerler alır. Örneğin, on-failure politikası, servis başarısız çıktığında (exit code 1-255 veya sinyal ile sonlandığında) otomatik yeniden başlatmayı tetikler. Bu, geçici hatalarda sistemi korurken, kalıcı sorunlarda manuel müdahaleye yer bırakır. Varsayılan olarak çoğu servis no politikasıyla çalışır, yani manuel müdahale gerektirir.

Politika seçiminde RestartSec= ve StartLimitIntervalSec= gibi ek direktifler önemlidir. RestartSec=, yeniden başlatma arasındaki bekleme süresini saniye cinsinden tanımlar (varsayılan 100ms), StartLimitBurst= ise belirli bir sürede (StartLimitIntervalSec= ile) maksimum yeniden başlatma sayısını sınırlar (varsayılan 5/10s). Bu mekanizmalar, sonsuz döngüleri önleyerek kaynak israfını engeller. Kurumsal ortamlarda, bu ayarlar servis yüküne göre optimize edilmelidir; örneğin, yüksek trafikli web sunucularında always politikası ile agresif yeniden başlatma tercih edilebilir.

Restart Policy’sini Yapılandırma Adımları

Servis restart politikasını değiştirmek için öncelikle servis birim dosyasını düzenleyin. Ubuntu Server’da, systemctl edit komutu override dosyası oluşturarak orijinal dosyayı bozmaz. Örneğin, nginx servisi için şu adımları izleyin: Önce systemctl edit nginx komutunu çalıştırın, ardından [Service] bölümüne Restart=on-failure ve RestartSec=5s ekleyin. Değişiklikleri kaydetmek için Ctrl+O ve Ctrl+X kullanın, sonra systemctl daemon-reload ile systemd’i güncelleyin. Servisi yeniden yükleyin: systemctl restart nginx.

• Servis durumunu kontrol edin: systemctl status nginx ile restart policy’sinin uygulandığını doğrulayın.
• Test için servisi öldürün: pkill -9 nginx, ardından logları inceleyin: journalctl -u nginx -f.
• StartLimit ayarları ekleyin: StartLimitIntervalSec=60 ve StartLimitBurst=3 ile dakikada 3’ten fazla restart’ı engelleyin.

Bu adımlar, drop-in dosyalar (/etc/systemd/system/nginx.service.d/override.conf) üzerinden kalıcı hale getirilir. Üretimde, değişiklikleri test ortamında doğrulayın ve etki analizi yapın. Bu yöntem, paket güncellemelerinde ayarlarınızın korunmasını sağlar.

Pratik Örnekler ve En İyi Uygulamalar

Web Sunucusu İçin Always Politikası

Apache2 servisi için always politikası, her türlü sonlandırmada (success dahil) yeniden başlatmayı sağlar. Unit dosyasında [Service] altına Restart=always, RestartSec=2s ekleyin. Bu, bellek sızıntısı olan uzun süreli servislerde idealdir. Örnek: Yüksek yük altında Apache’nin 10 dakikada bir restart olması için StartLimitIntervalSec=600 ve StartLimitBurst=1 tanımlayın. Uygulama sonrası, journalctl ile restart loglarını filtreleyin: journalctl -u apache2 –since “10 minutes ago”. Bu yaklaşım, %99.9 uptime hedeflerine katkı sağlar.

Veritabanı Servisi İçin On-Failure Politikası

MySQL için on-failure, yalnızca hatalı çıkışlarda restart yapar. systemctl edit mysql ile Restart=on-failure, RestartSec=10s ayarlayın. Kritik veritabanlarında SuccessExitStatus=0 1 ile başarılı çıkışları tanımlayın. Ek olarak, WatchdogSec=30 ile watchdog mekanizmasını etkinleştirin; servis düzenli heartbeat göndermezse restart olur. Test: mysqladmin shutdown ile simüle edin ve recovery süresini ölçün. Bu, veri bütünlüğünü korurken otomatik iyileşmeyi sağlar.

Özel Servisler İçin Gelişmiş Limitler

Özel bir Python uygulamasında, on-abnormal politikası timeout veya OOM killer durumlarında restart’ı tetikler. Unit dosyasına Restart=on-abnormal, StartLimitIntervalSec=300, StartLimitBurst=4 ekleyin. TimeoutStopSec=30 ile uzun çalışan işlemleri sınırlayın. İzleme için systemd’nin RateLimitIntervalSec= özelliğini kullanın. Bu konfigürasyon, kaynak yoğun servislerde dengeli davranışı garanti eder ve manuel müdahaleyi minimize eder.

Systemd restart policy’lerini etkin kullanmak, Ubuntu Server’larda operasyonel verimliliği artırır. Pratik adımları takip ederek, servislerinizi failure-tolerant hale getirin ve düzenli log incelemeleriyle performansı optimize edin. Bu stratejilerle, kurumsal düzeyde güvenilirlik elde edebilirsiniz.