Bastan Başlatma Hatalarını Sistem Yüzeyinde Analiz Etmek: systemd ile başlanmış bir inceleme rehberi

Giriş ve motivasyon
Bir Linux sistemi açılırken veya yeniden başlatılırken hizmetlerin veya hedeflerin başarısız olması, sistem güvenilirliğini doğrudan etkiler. systemd, başlatma süreçlerini hiyerarşik hedefler ve birimlerle temsil eder. Bu yazıda, başlangıç hatalarını sistemli bir şekilde analiz etmek için temel komutları, günlük konumlarını ve yaygın durum kodlarını ayrıntılı olarak ele alacağım. Amacım, tek tek birim yerine bütünsel bir görünüm sunmak ve sorunları izleme, yeniden başlatma ve kalıcı çözümler için bir yol haritası önermek.

• systemd’nin temel yapısı, hedefler (targets) ve bunlara bağlı birimlerdir. multi-user.target veya graphical.target gibi hedefler, hangi servislerin başlayacağını belirler.
• Birim türleri: servisler (service), cihazlar (device), zamanlayıcılar (timer), mount noktaları (mount), socketler (socket) vb.
• Başlatma zincirinde sorun gördüğünüzde, hangi hedefin başarısız olduğuna bakmak, sorunu daraltmaya başlar. Örneğin, multi-user.target başarısızsa tüm kullanıcı alanı servisleri etkilenir.

• Genel durum kontrolü: systemctl is-system-running
• Aktifimser durumlar ve hatalar: systemctl --failed
• Başlatma süreçlerini izlemek için günlükler: journalctl -xe ve journalctl -u
• Hedef odaklı inceleme: systemctl list-dependencies multi-user.target
• Sorunlu birimin yeniden yüklenmesi: systemctl daemon-reload ve systemctl restart
• Otomatik başlatma kontrolü: systemctl enable/disable

• Bağımlılık sorunları: birimlerin birbirine bağımlı olduğu durumlarda, eksik veya bozulmuş bağımlılıklar başlar. Bu durumda loglarda “dependency failed” ifadesi belirginleşir. Çözüm, hatalı bağımlılığı tamir etmek veya geçici olarak bağımlılık akışını yeniden yapılandırmaktır.
• Erişim ve dosya izinleri: servisler için gerekli olan dosya yolu veya izinler hatalıysa başlatma başarısız olur. Deneme olarak dosya izinlerini, SELinux veya AppArmor politikalarını kontrol etmek gerekir.
• Konfigürasyon hataları: yanlış yol, değişken eksikliği veya hatalı syntax loglarda belirginleşir. journalctl -u ile konfigürasyon yüklemesini yeniden tetiklemek faydalı olabilir.
• Ağ tabanlı bağımlılıklar: bazı servisler ağ üzerinde var olan kaynaklara bağımlıdır. Ağ çökmeleri veya DNS sorunları başlatmayı engeller. Çözüm, bağımlı hizmetlerin durumunu kontrol etmek ve gerektiğinde zamanlayıcı ile yeniden denemeyi ayarlamaktır.

• Başlatma süresinin izlenmesi: systemd-analyze blame ile hangi birimlerin en çok zaman aldığını görmek, darboğazları ortaya koyar.
• Başlatma planını görselleştirme: systemd-analyze critical-chain komutu, hangi birimlerin hangi aşamada birbirini beklediğini gösterir.
• Yapılandırmayı sürdürme: enable/disable ile gereksiz birimleri kapatmak, hedefleri temiz ve bağımlılıkları minimize etmek, ve gereğinde systemd-analyze verify ile konfigürasyon doğrulamasını yapmak.
• Günlük arşivi bütünlüğü: journal'ların disk alanı sorunları veya arşivleme politikaları nedeniyle kayda değer bilgiler kaybolabilir. Durumları korumak için günlük boyutu ve zaman aralığını uygun şekilde ayarlamak gerekir.

• Sorun: boot raportunda “Failed to start NetworkManager” hatası görünüyor.
• Adımlar: journalctl -u NetworkManager -b ile günlüğü incelemek; systemctl status NetworkManager ile anlık durumunu görmek; bağımlı birimlerin durumunu kontrol etmek; ağ servisinin düzgün çalışması için NetworkManager’ın konfigürasyonunun doğruluğunu kontrol etmek; gerekirse yeniden başlatıp daemon-reload yapmak.
• Sonuç: Bağımlı ağ çözümleniyor, ardından diğer bağımlılıklar tek tek kontrol edilerek başlatma akışı normale dönüyor.