Gözetim mekanizmamız, bilerek durdurduğumuz servisleri yeniden başlattı

Operasyonlar2026-10-31

Gözetim mekanizmalarımızdan biri, etkin ancak çalışmayan servislerimizi başlatır. Ekim ayında iki kez, bilerek durdurduğumuz servisleri başlattı. İkinci seferde, sitelerimizden birini ziyaret edenler yaklaşık 45 dakika boyunca hatalarla karşılaştı.

Bu gözetim mekanizmasının var olma nedeni

SIGTERM aldığında temiz bir şekilde çıkan bir servis, örneğin adıyla sonlandırıldığı için, systemd açısından "başarısız" sayılmaz. Restart=on-failure onu geri getirmez ve systemctl --failed onu listelemez. Biri fark edene kadar kapalı kalır. Bu yüzden gözetim mekanizması, etkin ancak çalışmayan servisleri arar ve onları başlatır.

Sorun şu ki, elle durdurduğunuz bir servis tıpatıp aynı görünür.

İlk sefer

7 Ekim'de, iş kuyruğunu düzenlemek için 12:47'de systemctl stop komutuyla bir video işçisini durdurduk. 12:55'te tekrar çalışıyordu: gözetim mekanizması onu başlatmıştı.

İkinci sefer

21 Ekim'de, sitelerimizden ikisine de hizmet veren makinenin belleğine bir model testi için ihtiyacımız vardı. Bir betik, sitelerin web uygulamalarını, bir senkronizasyon işini ve bir veritabanı konteynerini yine systemctl stop ile durdurdu. Yaklaşık beş dakika sonra siteleri izleyen bir zamanlayıcı ve 19:14'te gözetim mekanizması, tüneli ve web uygulamalarını geri getirdi.

Tünel tekrar trafik almaya başladı, ancak web uygulamaları yanıt veremiyordu: test edilen model, makinenin belleğinin 114 GiB'ini işgal ediyordu. Yaklaşık 19:14'ten 20:00'e kadar bazı ziyaretçiler 502 hataları aldı. 20:00'de tüneli, web uygulamalarını ve senkronizasyon işini devre dışı bıraktık ve izleme zamanlayıcısını durdurduk.

Şu anda kullandığımız kural

Bir servisi devre dışı bırakarak duraklatın: sudo systemctl disable --now <unit>. sudo systemctl enable --now <unit> ile geri getirin. Gözetim mekanizmamız yalnızca etkin servisleri incelediği için, devre dışı bırakılan bir servise dokunmaz.
Onu geri getirebilecek her şeyi duraklatın: önündeki tüneli ve onu izleyen herhangi bir zamanlayıcıyı.
Kısa süreli bir durdurma bir yarış halidir. Yalnızca stop kullanıyorsanız, bir sonraki kontrolden önce işinizi bitirin; bu kontrol makinelerimizde dakikalar içinde gelir.

Aynı aylardan iki systemd tuzağı daha

/etc/systemd/system konumundaki bir birim dosyası için systemctl mask --runtime hiçbir şey yapmaz. /etc altındaki birimler, /run altındaki çalışma zamanı maskelemesine öncelik verdiğinden, komut başarılı olur ve hizmet yine de başlar. Bir hizmeti durdurmak için ConditionPathExists=!/etc/<name>.hold içeren bir drop-in dosyası kullanırız: bu dosya var olduğu sürece, hizmet ne açılışta ne de elle başlatılır.
systemctl is-active, çalışan bir oneshot hizmetini inactive olarak bildirir. Bir Type=oneshot hizmeti çalışırken durumu "activating" olur; bu yüzden is-active bunu yazar ve 3 döndürür. Bir gecelik işi beklemek için yazılmış while systemctl is-active --quiet job.service; do sleep 60; done gibi bir döngü hemen çıkar. Bunun yerine durumu okuyun: active, activating, reloading veya deactivating durumlarının hepsi hizmetin hâlâ çalıştığını gösterir.

Factory Floor, etkin ancak çalışmayan hizmetleri izler. Varsayılan olarak yalnızca bunları raporlar ve ancak siz açarsa başlatır. 1.0.3 sürümünden itibaren uyarısı, bir hizmeti kasıtlı olarak nasıl duraklatacağınızı da söyler ve runbook aynı bilgiyi içerir.