Teknik Rehber · Linux ve Sistem Yönetimi

Systemd Bağımlılıkları: After, Wants ve Requires ile Servis Tasarımı

After yalnız sıralama tanımlar; diğer servisi otomatik başlatmaz. Wants zayıf, Requires daha güçlü gereksinim ilişkisi kurar; sıralama yine ayrı tanımlanır. Servis A’nın B’den sonra…

Teknik gözden geçirme: 2026-10-06

Mimari ve çalışma modeli

Network-online.target açılışta ağın yönetici tanımına göre hazır olmasını bekleyebilir; sürekli uzak sunucu erişilebilirliği garantisi vermez. Uygulama DNS veya veritabanına bağlanamıyorsa bounded retry ve readiness tasarımı gerekir. Kör sleep süreleri bağımlılık hatasını gizler.

Oneshot, simple ve notify servis tiplerinin hazır kabul edilme koşulları farklıdır. Drop-in ile değişiklik yapıp daemon-reload sonrası effective unit’i kontrol edin. Döngüsel bağımlılıkta daha fazla Requires eklemek yerine en küçük gerekli ilişkiyi yeniden çizin.

1Unit gereksinimi
2Sıralama grafiği
3Process ve readiness
4Retry ve sağlık

Etkin unit’i inceleyin.

Tasarım parametreleri

Başlatma ihtiyacı: Sıralama ile servis çağırmayı ayrı seçin; Wants/Requires gereksinime göre kullanılır.
Readiness: Process varlığı, port dinleme ve uygulama health sonucu aynı değildir.
Retry sınırı: RestartSec ve uygulama retry bütçesini aşırı restart döngüsü yaratmadan planlayın.

Hesap ve uygulama örneği

API servisi PostgreSQL’den sonra başlamalı fakat DB kesintisinde kontrollü 503 dönebiliyorsa zorunlu stop bağı yerine sıralama ve uygulama retry daha uygun olabilir. Bir labda DB başlangıcını 20 saniye geciktirin; API’nın başlaması, hazır olması ve ilk başarılı sorgusunu ayrı zamanlarda ölçün.

Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.

systemctl cat lab-api.service
systemctl show lab-api.service -p After -p Wants -p Requires
systemd-analyze critical-chain
journalctl -u lab-api.service -b

Hata teşhisi

Belirti	Olası neden / ayrım	Doğrulama
After var, DB başlamıyor	Sıralama aktivasyon değildir.	Wants/Requires ve transaction grafiğini inceleyin.
Cycle detected	Karşılıklı sıralama bağı.	Unit ve drop-in’leri birlikte okuyun.

Kabul ve doğrulama kontrolleri

Etkin unit’i inceleyin.
Sıralama/aktivasyonu ayırın.
Readiness’i uygulamada test edin.
Boot gecikmesini ölçün.
Kesinti retry’ını sınayın.
Drop-in geri almayı doğrulayın.

İlgili kavramlar

Bağımlılık ve geri açılış sırası

Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.

Servis yaşam döngüsü ve bağımlılıklar

Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Telemetri ve zaman eşleştirmesi

Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.

Dosya izinleri ve servis kimliği

Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi