systemctl --failed Çıktısı Nasıl Okunur? Arızalı Birimi İzleme

Yorumlar

systemctl --failed çıktısı bir hata listesi verir; fakat kök nedeni vermez. Listelenen birim yalnızca başka bir bağımlılığın, hatalı yapılandırmanın veya eksik kaynağın görünen sonucu olabilir. İncelemeyi birim durumundan çıkış koduna, günlükten bağımlılıklara doğru daraltmak gerekir.

Listeyi sistem ve kullanıcı birimleri olarak ayırın

BASH

systemctl --failed --no-pager
systemctl --user --failed --no-pager

Sistem yöneticisi olarak ilk komut sistem birimlerini, ikinci komut oturum kullanıcısının birimlerini gösterir. Bir servis failed durumuna geçmiş olabilir; bir mount, socket veya timer birimi de aynı listede bulunabilir. Bu nedenle yalnızca .service kayıtlarına odaklanmayın.

Durum çıktısındaki ilk kanıtları okuyun

BASH

systemctl status example.service --no-pager --full

Şu alanları ayırın:

Loaded: Birim dosyasının yolu ve etkinlik durumu.
Active: Hatanın zamanı ve birimin mevcut durumu.
Process: Çalıştırılan komut ile çıkış kodu.
Son journal satırları: Hemen önceki hata mesajları.

Durum çıktısı genellikle günlüğün yalnızca son bölümünü gösterir. Kesilmiş satırları ve önceki denemeleri görmek için journal'a geçin.

Makine tarafından okunabilir sonuç alanlarını alın

BASH

systemctl show example.service \
  -p Result -p ExecMainCode -p ExecMainStatus \
  -p ActiveState -p SubState -p NRestarts

Result=exit-code uygulamanın sıfırdan farklı kodla çıktığını, Result=timeout tanımlı süre içinde tamamlanmadığını, Result=signal ise bir sinyalle sona erdiğini gösterir. ExecMainStatus uygulamanın çıkış kodunu veya sinyal numarasını taşır; uygulamanın kendi kılavuzuyla birlikte yorumlanmalıdır.

Yalnızca ilgili boot ve zaman aralığını okuyun

BASH

sudo journalctl -u example.service -b --no-pager
sudo journalctl -u example.service \
  --since '2026-09-01 09:50:00' --until '2026-09-01 10:10:00' --no-pager

-b mevcut açılışa sınırlar. Hata daha önceki açılışta oluştuysa journalctl --list-boots ile boot listesini görüp -b -1 gibi bir seçim kullanabilirsiniz. Zaman aralığı, aynı servise ait yüzlerce ilgisiz satırı elemenizi sağlar.

Çalıştırılan komutu ve birim dosyasını doğrulayın

BASH

systemctl cat example.service
systemctl show example.service -p FragmentPath -p DropInPaths -p ExecStart
systemd-analyze verify /etc/systemd/system/example.service

systemctl cat, ana dosyayla drop-in ayarlarını birlikte gösterir. Bir paket güncellemesinden sonra yerel override beklenmeyen değeri geçersiz kılmış olabilir. systemd-analyze verify birim dosyası sözdizimini ve bazı bağımlılık sorunlarını çalıştırmadan denetler.

Bağımlılık hatasını asıl kaynağına kadar izleyin

BASH

systemctl list-dependencies example.service
systemctl list-dependencies example.service --reverse
systemctl --failed --type=mount --no-pager

Servis “dependency failed” mesajıyla durduysa ağ, mount, socket veya başka bir servis önce başarısız olmuş olabilir. Görünen servisi tekrar tekrar başlatmak yerine ilk hata zamanına sahip bağımlılığı inceleyin.

Yeniden denemeyi kontrollü yapın

Yapılandırmayı düzelttikten sonra gerekiyorsa:

BASH

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl status example.service --no-pager
systemctl --failed --no-pager

systemctl reset-failed example.service hata sayacını ve failed durumunu temizler; arızayı onarmaz. Önce nedenin giderildiğini ve servisin sağlıklı başladığını kanıtlayın. Restart döngüsündeki bir serviste tekrar sayısını yükseltmek yerine uygulamanın ilk çıkış nedenini bulun.

İnceleme tamamlandığında yalnızca listenin boşalmasına değil, servisin beklenen portu açmasına, dosyayı üretmesine veya isteğe yanıt vermesine bakın. systemd açısından “active” olmak uygulamanın işlevsel olarak sağlıklı olduğunu tek başına kanıtlamaz.

Teknik başvuru: systemctl, systemd.service ve journalctl kılavuzları.