Linux VDS’de bir uygulama yanıt vermediğinde ilk tepki çoğu zaman servisi yeniden başlatmaktır. Bu işlem bazen erişimi geri getirse de kaybolan bağlam ve tekrar eden hata nedeni yüzünden kalıcı çözümü zorlaştırabilir. systemd kullanan dağıtımlarda önce servis durumunu ve beklenen çalışma biçimini ayırın. Genel kaynak takibi için VDS izleme rehberi ayrı bir katman sağlar.
Durum bilgisini okuyun, değiştirmeyin
systemctl status uygulama.service --no-pager örneğinde birim adını kendi kurulu uygulamanızla değiştirin. Bu sorgu durum incelemesidir. systemctl belgesi active, inactive ve failed durumlarını ve durum çıktısının kapsamını açıklar. Durumun normal olup olmadığı uygulamanın çalışma türüne bağlıdır; yalnız yeşil veya kırmızı kelimeye bakarak karar vermeyin.
Çıktıda görünen zaman, ana işlem ve son hata satırlarını not edin. Terminalde görülen kısa kayıt tüm geçmişi temsil etmeyebilir. Birim adı bulunamadığında rastgele başka bir servisi denemek yerine kurulu paketin belgesine dönün. Aynı sunucuda birden fazla sürüm veya örnek varsa hangi uygulamanın gerçekten trafiği karşıladığını belirleyin.
Çalıştırılan komut ve bağlamı kontrol edin
systemctl cat uygulama.service birim tanımını incelemeye yardımcı olur; ancak içerikte gizli değerler bulunabileceğinden çıktıyı açık foruma koymayın. Çalıştırılan dosya yolu, kullanıcı ve varsa ek ayar dosyası beklediğiniz kurulumla uyumlu mu? Dosya mevcut değilse veya izin hatası varsa bunu kaydedin. Her yere tam izin vermek ya da servis kullanıcısını en yetkili hesaba çevirmek teşhis değildir.
Hata hangi değişiklikten sonra başladı?
Son paket güncellemesi, uygulama ayarı, sertifika yenilemesi veya disk doluluğu olayını zaman çizelgesine ekleyin. Kaynak yetersizliği düşünüyorsanız Linux RAM ve cache rehberindeki kullanılabilir bellek ayrımını hatırlayın; yüksek cache tek başına servis arızası değildir. Disk işlemlerini değerlendirirken disk testi rehberini yoğun üretim işinden ayrı planlayın, arızanın ortasında yük testi başlatmayın.
Müdahaleyi iş etkisiyle birlikte planlayın
Yeniden başlatma gerekiyorsa açık işlemleri, sıradaki işleri ve geri dönüş yolunu düşünün. Sürekli yeniden başlatma döngüsü, uygulama yapılandırması hatasını iyileştirmez. Hata durumunu sıfırlamak da nedeni ortadan kaldırmak değildir. Yeni yapılandırmayı uygulamadan önce üreticinin desteklediği doğrulama yöntemini kullanın ve mevcut ayar kopyasını koruyun.
VDS desteğine servis adı, sorun başlangıcı, son değişiklik ve hassas alanları temizlenmiş durum çıktısını iletin. Uygulama kodu, işletim sistemi servisi ve hizmet sağlayıcı ağı farklı sorumluluk alanlarıdır. Hangi katmanın hata verdiğini gösteren kısa kayıt, kontrolsüz restart veya paket büyütme denemelerinden daha yararlıdır.
Servis tekrar çalıştıktan sonra yalnız durum satırını değil gerçek iş sonucunu da kontrol edin. Web servisi için yetkili test adresi, arka plan işi için beklenen test çıktısı seçilebilir. Tekrar eden hataları izlemek üzere sorumluyu ve takip zamanını belirleyin. Başarı ölçütünü önceden tanımlamak, kısa süreli toparlanmayı kalıcı çözüm sanma riskini azaltır.
Sıkça Sorulan Sorular
Failed görünce hemen restart yapmalı mıyım?
Önce hata kaydı ve uygulama durumu korunmalı. Yeniden başlatmanın iş etkisi ve tekrar eden hata nedeni değerlendirilmelidir.
Inactive her zaman arıza mı?
Hayır. Servisin beklenen çalışma türüne bağlıdır; tek seferlik işin tamamlanması ile beklenmeyen kapanma farklıdır.
Enable komutu servisi başlatır mı?
Etkinleştirme ve mevcut anda çalıştırma farklı konulardır. Komutu anlamadan kopyalamak yerine amaç ve bağımlılıkları inceleyin.
Servis adını nasıl seçmeliyim?
Kurulu uygulamanın gerçek birim adını kullanın. Dağıtım veya paket sürümüne göre isim değişebilir; örneği doğrudan üretime taşımayın.