Servis Otomatik Yeniden Başlatma Yapılandırması
systemd ile servislerin çökmesi durumunda otomatik yeniden başlatma, sağlık kontrolü ve izleme yapılandırması rehberi.
İçindekiler
Giriş
Üretim ortamında servislerin beklenmedik şekilde çökmesi kaçınılmazdır. Doğru yapılandırılmış otomatik yeniden başlatma mekanizmaları, kesinti süresini minimize eder ve sistem güvenilirliğini artırır. Bu rehberde systemd ile servis otomatik yeniden başlatma yapılandırmasını ele alacağız.
Neden Otomatik Yeniden Başlatma?
- Bellek sızıntısı veya beklenmedik hata sonrası servis çöker
- Geçici ağ sorunları servisi etkiler
- Bağımlı servis geç başlar ve ana servis başlangıçta başarısız olur
- Kernel OOM killer servisi öldürür
Adım 1: Mevcut Servis Durumunu Kontrol Et
# Servis durumu
systemctl status servis_adi
# Servis logları
journalctl -u servis_adi -n 50
# Son çökmeler
journalctl -u servis_adi --since "24 hours ago" | grep -i -E '(fail|error|crash|killed|exit)'
# Servis yeniden başlatma sayısı
systemctl show servis_adi | grep -E '(NRestarts|ActiveState|SubState)'
Adım 2: systemd Otomatik Yeniden Başlatma Yapılandırması
Temel Yapılandırma
# Servis dosyasını düzenle
sudo systemctl edit servis_adi
# Veya doğrudan servis dosyasını düzenle
sudo nano /etc/systemd/system/servis_adi.service
[Unit]
Description=Benim Servisim
After=network.target
[Service]
Type=simple
User=www-data
ExecStart=/usr/bin/uygulama
Restart=always
RestartSec=5
StartLimitIntervalSec=60
StartLimitBurst=5
[Install]
WantedBy=multi-user.target
Restart Seçenekleri
| Seçenek | Açıklama |
|---|---|
Restart=no | Otomatik yeniden başlatma yok (varsayılan) |
Restart=always | Her durumda yeniden başlat |
Restart=on-failure | Sadece hata durumunda yeniden başlat |
Restart=on-abnormal | Anormal çıkışta yeniden başlat |
Restart=on-abort | Sinyal ile öldürülünce yeniden başlat |
# Yapılandırmayı yeniden yükle ve servisi başlat
sudo systemctl daemon-reload
sudo systemctl enable servis_adi
sudo systemctl start servis_adi
Adım 3: Gelişmiş Yeniden Başlatma Yapılandırması
Yeniden Başlatma Limiti
[Service]
Restart=on-failure
RestartSec=10
# 5 dakika içinde 5 kezden fazla başarısız olursa durdur
StartLimitIntervalSec=300
StartLimitBurst=5
Bellek Limiti ile Otomatik Yeniden Başlatma
[Service]
Restart=always
RestartSec=5
# 512MB'ı aşarsa servisi yeniden başlat
MemoryMax=512M
MemoryHigh=400M
Watchdog ile Sağlık Kontrolü
[Service]
Restart=on-failure
RestartSec=5
# 30 saniyede bir watchdog ping'i bekle
WatchdogSec=30
NotifyAccess=main
Watchdog kullanmak için uygulamanın sd_notify(SD_WATCHDOG) çağrısı yapması gerekir. Node.js için systemd npm paketi kullanılabilir.
Adım 4: Uygulama Bazlı Yapılandırmalar
Nginx
# Nginx zaten systemd ile yönetiliyor
systemctl status nginx
# Nginx'in otomatik yeniden başlatma durumu
systemctl show nginx | grep Restart
# Override ile yapılandır
sudo systemctl edit nginx
[Service]
Restart=always
RestartSec=3
Node.js Uygulaması
[Unit]
Description=Node.js Uygulamam
After=network.target
[Service]
Type=simple
User=nodeuser
WorkingDirectory=/var/www/app
ExecStart=/usr/bin/node /var/www/app/index.js
Restart=always
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp
[Install]
WantedBy=multi-user.target
Docker Container
# docker-compose.yml
services:
app:
image: myapp
restart: unless-stopped # always, on-failure, no
# veya
restart: on-failure:5 # Maksimum 5 kez yeniden başlat
# Docker restart policy
docker update --restart=unless-stopped container_adi
Adım 5: Servis Bağımlılıkları
[Unit]
Description=Web Uygulamam
After=network.target mysql.service redis.service
Requires=mysql.service
Wants=redis.service
[Service]
Restart=on-failure
RestartSec=10
# MySQL hazır olana kadar bekle
ExecStartPre=/bin/sh -c 'until mysqladmin ping -h localhost; do sleep 2; done'
Adım 6: İzleme ve Bildirim
systemd ile E-posta Bildirimi
# /etc/systemd/system/servis-failure-notify@.service
[Unit]
Description=Servis Hata Bildirimi
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo "Servis %i çöktü: $(date)" | mail -s "Servis Hatası" admin@example.com'
# Ana servis dosyasına ekle
[Unit]
OnFailure=servis-failure-notify@%n.service
Uptime Kuma ile İzleme
# Uptime Kuma kurulumu için
# bilgi-bankasi/self-hosting/uptime-kuma-kurulum makalesine bakın
# Servis sağlık endpoint'i ekle
# GET /health → 200 OK döndürmeli
Adım 7: Sorun Giderme
# Servis neden başlamıyor?
journalctl -u servis_adi -n 100 --no-pager
# systemd servis durumu detayları
systemctl status servis_adi -l
# Yeniden başlatma döngüsünü kontrol et
systemctl show servis_adi | grep -E '(NRestarts|ActiveEnterTimestamp|InactiveEnterTimestamp)'
# Servis başlatma geçmişi
journalctl -u servis_adi --since "1 hour ago" | grep -E '(Started|Stopped|Failed|Restarting)'
# Tüm başarısız servisleri listele
systemctl --failed
StartLimitBurst limitine ulaşıldığında systemd servisi otomatik olarak durdurmayı bırakır. systemctl reset-failed servis_adi komutuyla sayacı sıfırlayabilirsiniz.
Sonuç
Systemd ile otomatik yeniden başlatma yapılandırması, üretim ortamında servis güvenilirliğini önemli ölçüde artırır. Restart=always veya Restart=on-failure ile temel yapılandırmayı yapın, RestartSec ile yeniden başlatma aralığını ayarlayın ve StartLimitBurst ile sonsuz döngüyü önleyin. Uptime Kuma gibi izleme araçlarıyla servis durumunu sürekli takip edin.
İlgili Makaleler
SSH Bağlantı Sorunu: Sunucuya Bağlanamıyorum
SSH bağlantı sorunlarını çözme rehberi: Path.net firewall kuralları, Default Block, SSH portu için filtre kuralı oluşturma ve sorun giderme adımları.
RDP Bağlantı Sorunu: Windows Sunucuya Erişilemiyor
RDP bağlantı sorunlarını çözme rehberi: Path.net firewall kuralları, Default Block, RDP portu için filtre kuralı oluşturma ve sorun giderme adımları.
MTR Testi Nasıl Yapılır ve Destek Ekibine Gönderilir
WinMTR ve Linux MTR ile ağ testi yapma, ICMP filtre kuralı oluşturma ve sonuçları destek ekibine gönderme rehberi. Paket kaybı ve gecikme analizi.