Bir servis açılmadığında peş peşe restart vermek, ilk hatayı yeni kayıtların arasında kaybettirebilir. Daha sağlam başlangıç, servisin hangi aşamada durduğunu görmek ve o ana ait veriyi toplamaktır. systemd kullanan Linux dağıtımlarında birkaç sorgu, araştırılacak alanı belirgin biçimde daraltır.
Buradaki komutlar teşhis amaçlıdır; servis ayarını değiştirmez. Örneklerdeki uygulama.service adını gerçek unit adıyla değiştirin. Günlük okuma yetkileri dağıtıma ve kullanıcıya göre değişebilir. Yetki hatasını, servisin hiç kayıt üretmediği şeklinde yorumlamayın.
Durumu ve zamanı beraber okuyun
systemctl status uygulama.service --no-pager -l
systemctl is-enabled uygulama.service
systemctl --failed
İlk çıktıda yüklenen unit dosyasına, Active alanına, süreç çıkış bilgisine ve zaman damgasına bakın. Servisin açılışta etkinleştirilmiş olması, şu anda çalıştığını göstermez. Tersi de mümkündür: elle başlatılmış bir servis çalışıyor olabilir, ancak sonraki açılış için etkin değildir. Bu ayrım Red Hat’in systemctl rehberinde açıklanıyor.
Active alanını uygulamanın işlevsel sağlık kontrolüyle tamamlayın. Süreç ayakta olsa bile beklenen portu dinlemiyor, veritabanına bağlanamıyor veya kullanıcı isteğine cevap veremiyor olabilir. Önce hangi davranışın bozuk olduğunu tek cümleyle tarif edin.
Günlüğü ilgili açılışa daraltın
journalctl -u uygulama.service -b --no-pager
journalctl -u uygulama.service --since "30 minutes ago" --no-pager
İlk komut mevcut sistem açılışını, ikincisi yakın zaman aralığını inceler. Çok sayıda kayıt varsa olay saatine göre daha dar bir aralık seçin. Journal inceleme dokümanı, unit ve açılış filtrelerinin nasıl birlikte kullanılacağını gösteriyor.
Yalnızca son hata satırını okumayın. Yapılandırma dosyasının bulunamaması, erişim reddi veya port çakışması genellikle kapanış mesajından önce görünür. Kayıtları paylaşmadan önce bağlantı dizelerini, kullanıcı bilgilerini ve varsa sırları ayıklayın. Eski açılışın kayıtları tutulmuyorsa bunu rapora açıkça yazın.
Çalışan tanımla dosyadaki tanımı karşılaştırın
systemctl cat uygulama.service
systemctl show uygulama.service -p FragmentPath -p DropInPaths -p User -p Group -p ExecStart
systemctl list-dependencies uygulama.service
Paketin ana unit dosyasının yanında yerel drop-in dosyaları bulunabilir. Servis kullanıcısı, çalıştırılacak dosya yolu ve çalışma dizini beklenen değerlerle uyuşuyor mu? Komut elle çalışırken servis olarak hata veriyorsa ortam değişkenleri ve kimlik bağlamı özellikle önem kazanır.
systemctl komutlarının farklı bilgi kaynaklarını gösterdiğini projenin kendi başvurusundan kontrol edebilirsiniz. Bağımlılık listesini görmek, bağlı servisin gerçekten hazır olduğunu tek başına kanıtlamaz; ilgili bileşenin sağlık kontrolü ayrıca yapılmalıdır.
Değişikliği küçük tutun
Hata bulunduğunda bütün unit dosyasını yeniden yazmak yerine gerekli en küçük değişikliği planlayın. Önce mevcut dosyayı ve yerel ekleri yedekleyin, uygulamanın desteklediği yapılandırma doğrulamasını kullanın. Unit değişikliğini systemd’ye okutmakla uygulamanın kendi yapılandırmasını yeniden yüklemek farklı işlemlerdir; gereken adımı kurulu sürümün dokümanına göre seçin.
Restart bağlantıları kesebilir; bakım penceresini ve geri dönüşü önceden belirleyin. Sonrasında aynı durum ve günlük sorgularını tekrarlayın, ardından gerçek bir uygulama isteğiyle doğrulayın. Olayı kapatırken hangi satırın değiştiğini ve hangi kontrolün geçtiğini yazmak, sonraki nöbetçi için en değerli bilgidir.
Yorumlar (0)
Henüz onaylanmış yorum yok.