- Konu sahibi
- #1
Sürekli yeniden başlayan bir servis nasıl teşhis edilir?
Sürekli yeniden başlayan bir servisi teşhis etmenin doğru yolu, önce servis yöneticisinin durumunu ve son çökme kayıtlarını koruyup incelemektir. Döngüyü durdurmak gerekiyorsa bunun hizmet etkisini değerlendirip kontrollü bakım penceresi kullanın. Linux üzerinde systemd kullanılıyorsa servis adıyla
systemctl status ve journalctl çıktıları alınır; ardından yapılandırma doğrulanır, hata kontrollü biçimde düzeltilir ve servis yeniden başlatılır. Tekrarlı başlatmalar status özetini değiştirip ilk hata izini kalabalıklaştırabilir; journal kayıtlarını sıfırlamak çözüm değildir.Sorun nasıl çalışır?
Ana işlemin kapanması her zaman başarısızlık değildir; kısa görev başarıyla tamamlanmış olabilir. Çıkış kodu, servis türü ve Restart politikası birlikte değerlendirilir. Servis dosyasında
Restart=always veya benzeri bir ayar varsa tekrar başlatma gerçekleşir. Kapanma; hatalı yapılandırma, eksik dosya, yanlış izin, kullanılamayan port, bozuk bağımlılık, yetersiz kaynak veya uygulamanın kendi iç hatası nedeniyle olabilir.Örneğin bir web servisi 443 numaralı portu dinlemek isterken başka bir işlem bu portu kullanıyorsa servis açılışta sonlanabilir. systemd yalnızca “servis başarısız oldu” bilgisini gösterir; gerçek neden çoğunlukla uygulamanın günlük kaydındaki son satırlardadır.
İlk teşhis adımları
Aşağıdaki örnekte
myservice yerine sorunlu servisin gerçek adını yazın. Yönetici yetkisi gerektiğinde komutların başına sudo ekleyin.- Servisin mevcut durumunu ve son hata satırlarını alın.
- Aynı servis için systemd günlüğünün son kayıtlarını inceleyin.
- Yeniden başlatma döngüsünü geçici olarak durdurun; böylece yeni kayıtların eski hatayı örtmesini engelleyin.
- Yapılandırmayı, bağımlılıkları, port kullanımını, disk alanını ve izinleri kontrol edin.
- Hata düzeltildikten sonra servisi yeniden başlatın ve durumunu tekrar doğrulayın.
Kod:
systemctl status myservice --no-pager -l
journalctl -u myservice -b --no-pager -n 100
systemctl stop myservice
# Asıl nedeni düzeltin ve uygulamanın yapılandırma testini geçirin
systemctl reset-failed myservice
systemctl start myservice
systemctl status myservice --no-pager -lstatus çıktısındaki Active: failed, code=exited, status=1/FAILURE veya bir sinyal bilgisi, yalnızca sonucun özetidir. Asıl açıklama için journalctl çıktısında error, fatal, permission denied, address already in use ve eksik dosya mesajlarını arayın.Sonucu yorumlama
Hata türüne göre izlenecek yol değişir. Aşağıdaki ayrım, sonraki kontrolü seçmeyi kolaylaştırır.
| Belirti | Muhtemel neden | Sonraki kontrol |
|---|---|---|
| Yapılandırma sözdizimi hatası | Yanlış veya eksik ayar | Uygulamanın yapılandırma testini çalıştırın |
| Address already in use | Portu başka işlem kullanıyor | Portu dinleyen işlemi belirleyin |
| Permission denied | Kullanıcı, dosya veya dizin izni | Servisin hangi kullanıcıyla çalıştığını ve dosya izinlerini kontrol edin |
| No such file veya dependency failed | Eksik dosya ya da başlatılmamış bağımlılık | Eksik bileşeni ve bağımlı servisleri doğrulayın |
| Killed veya out of memory | Bellek yetersizliği veya işletim sistemi müdahalesi | Çekirdek ve sistem günlüklerinde OOM kayıtlarını arayın |
Bu sınıflandırmadan sonra yalnız ilgili alanı düzeltin. Örneğin port çakışmasında uygulama ayarını rastgele değiştirmek yerine portu kimin kullandığını bulun. Yapılandırma hatasında ise servis çalışır durumdaymış gibi kabul edilmemeli; önce uygulamanın kendi test komutu başarıyla dönmelidir.
Daha derin kontrol
Günlükte neden görünmüyorsa servis tanımını ve çalışma koşullarını inceleyin:
Kod:
systemctl cat myservice
systemctl show myservice -p ExecStart -p User -p Group -p Restart -p MainPID -p NRestarts
systemctl list-dependencies myservice
ss -ltnp
df -h
free -hÇıktıda
ExecStart komutunun gerçekten mevcut olduğunu, User ve Group değerlerinin gerekli dosyalara erişebildiğini, bağımlı servislerin başarısız olmadığını kontrol edin. ss -ltnp port çakışmasını, disk ve bellek komutları ise kaynak yetersizliğini gösterebilir. MainPID değişimi yeni bir ana işleme işaret edebilir; tek başına çökme kanıtı değildir. Günlükteki exit status, zaman damgaları ve NRestarts ile doğrulayın.Uygulama destekliyorsa servisi systemd dışında, aynı kullanıcıyla ve ön planda çalıştırmak daha ayrıntılı hata verebilir. Bunu üretim sürecini bozmayacak bir bakım penceresinde yapın; aynı anda çalışan systemd örneği portu tuttuğu için önce servisi durdurun. Ön planda çalıştırmada hata görünmüyor ancak systemd altında servis kapanıyorsa çalışma dizini, ortam değişkeni, kullanıcı veya dosya yolu farklarını karşılaştırın.
Sık yapılan hatalar
- Yalnızca
restartkomutunu tekrarlamak: Hata düzelmediği için döngüyü gizler ve günlükleri gereksiz kayıtlarla doldurur. - Sadece
systemctl statusçıktısına bakmak: Bu çıktı özet bilgidir; uygulamanın gerçek hata mesajı ayrı günlükte bulunabilir. - Servis kullanıcı izinlerini root ile test etmek: Root başarılı olsa bile servis kendi kullanıcısıyla çalışırken dosyaya erişemeyebilir.
- Portu kullanan işlemi belirlemeden işlemi sonlandırmak: Bu, başka bir üretim servisini kesebilir. Önce işlemin ne olduğunu ve hangi servise ait olduğunu doğrulayın.
- Yapılandırmayı doğrudan değiştirmek: Önce mevcut dosyanın yedeğini alın ve uygulamanın yapılandırma testini çalıştırın.
Sık sorulan sorular
Servis hemen kapanıyor ama günlükte anlamlı hata yoksa ne yapılmalı?
Servis tanımındaki
ExecStart, çalışma kullanıcısı, çalışma dizini ve ortam değişkenlerini kontrol edin. Ardından servisi durdurup aynı çalıştırma komutunu aynı kullanıcıyla ön planda deneyin. Böylece systemd ile etkileşimden kaynaklanan farklar ortaya çıkabilir.Servis artık başlamıyor ve start limitine ulaştıysa sorun çözülmüş müdür?
Hayır. Bu durum yalnızca systemd'nin kısa sürede çok fazla başarısız başlatmayı sınırladığını gösterir. Önce günlüklerdeki asıl kapanma nedenini düzeltin; sonra
systemctl reset-failed ile başarısızlık sayacını sıfırlayıp servisi başlatın.