Watchdog-ul nostru a repornit serviciile pe care le oprise­sem intenționat

Operațiuni2026-10-31

Unul dintre watchdog-urile noastre pornește orice serviciu al nostru care este activat, dar nu rulează. De două ori în octombrie a pornit servicii pe care le oprise­sem intenționat. A doua oară, vizitatorii unuia dintre site-urile noastre au întâmpinat erori timp de aproximativ 45 de minute.

De ce există acel watchdog

Un serviciu care se termină curat când primește SIGTERM, de exemplu pentru că ceva l-a oprit pe nume, nu este considerat „eșuat” de systemd. Restart=on-failure nu îl repornește, iar systemctl --failed nu îl listează. Rămâne oprit până când cineva observă din întâmplare. Așadar, watchdog-ul caută servicii care sunt activate, dar nu rulează, și le pornește.

Problema este că un serviciu pe care l-ați oprit manual arată exact la fel.

Prima dată

Pe 7 octombrie am oprit un worker video cu systemctl stop la 12:47 pentru a edita coada sa de joburi. La 12:55 rula din nou: watchdog-ul îl pornise.

A doua oară

Pe 21 octombrie aveam nevoie de memoria mașinii care servește și două dintre site-urile noastre pentru un test de model. Un script a oprit aplicațiile web ale site-urilor, un job de sincronizare și un container de bază de date, din nou cu systemctl stop. Aproximativ cinci minute mai târziu, un timer care monitorizează site-urile, iar la 19:14 watchdog-ul, au repornit tunelul și aplicațiile web.

Tunelul a preluat din nou traficul, dar aplicațiile web nu puteau răspunde: modelul testat ocupa 114 GiB din memoria mașinii. De la aproximativ 19:14 până la 20:00, unii vizitatori au primit erori 502. La 20:00 am dezactivat tunelul, aplicațiile web și jobul de sincronizare, și am oprit timerul de monitorizare.

Regula pe care o folosim acum

• Pauzați un serviciu dezactivându-l: sudo systemctl disable --now <unit>. Reporniți-l cu sudo systemctl enable --now <unit>. Watchdog-ul nostru se uită doar la serviciile activate, deci unul dezactivat este lăsat în pace.
• Pauzați tot ce îl poate reporni: tunelul din fața lui și orice timer care îl monitorizează.
• O oprire scurtă este o cursă contra cronometru. Dacă folosiți doar stop, terminați înainte de următoarea verificare, care pe mașinile noastre are loc în câteva minute.

Încă două capcane systemd din aceleași luni

• systemctl mask --runtime nu face nimic pentru un fișier unit în /etc/systemd/system. Unitățile din /etc au prioritate față de masca din runtime din /run, deci comanda are succes și serviciul pornește oricum. Pentru a ține un serviciu în așteptare, folosim un drop-in cu ConditionPathExists=!/etc/<name>.hold: cât timp acel fișier există, serviciul nu va porni, nici la pornirea sistemului, nici manual.
• systemctl is-active raportează un serviciu oneshot în execuție ca inactiv. În timp ce un serviciu Type=oneshot rulează, starea lui este „activating”, deci is-active afișează acest lucru și returnează 3. O buclă precum while systemctl is-active --quiet job.service; do sleep 60; done, menită să aștepte o sarcină nocturnă, se termină imediat. Citiți mai degrabă starea: active, activating, reloading sau deactivating înseamnă toate că încă rulează.

Factory Floor monitorizează serviciile activate care nu rulează. În mod implicit, le raportează doar și le pornește doar dacă activați această opțiune. Începând cu versiunea 1.0.3, alerta sa indică și cum să puneți un serviciu în pauză intenționat, iar runbook-ul spune același lucru.