Vår overvåker startet tjenestene vi hadde stoppet med vilje

Drift2026-10-31

En av overvåkerne våre starter alle tjenestene våre som er aktivert, men ikke kjører. To ganger i oktober startet den tjenester vi hadde stoppet med vilje. Andre gangen fikk besøkende til en av nettstedene våre feil i omtrent 45 minutter.

Hvorfor denne overvåkeren finnes

En tjeneste som avsluttes ryddig når den mottar SIGTERM, for eksempel fordi noe drepte den ved navn, er ikke «feilet» så langt systemd er opptatt av. Restart=on-failure starter den ikke på nytt, og systemctl --failed lister den ikke opp. Den ligger nede til noen tilfeldigvis merker det. Derfor ser overvåkeren etter tjenester som er aktivert, men ikke kjører, og starter dem.

Problemet er at en tjeneste du stoppet manuelt, ser helt lik ut.

Første gang

Den 7. oktober stoppet vi en videobehandler med systemctl stop kl. 12:47 for å redigere jobbkøen dens. Kl. 12:55 kjørte den igjen: overvåkeren hadde startet den.

Andre gang

Den 21. oktober trengte vi minnet på maskinen som også tjener to av nettstedene våre, til en modeltest. Et skript stoppet nettstedenes nettapper, en synkroniseringsjobb og en databasecontainer, igjen med systemctl stop. Omtrent fem minutter senere startet en timer som overvåker nettstedene, og kl. 19:14 overvåkeren, tunnelen og nettappene opp igjen.

Tunnelen tok imot trafikk igjen, men nettappene kunne ikke svare: modellen under test holdt 114 GiB av maskinens minne. Fra omtrent 19:14 til 20:00 fikk noen besøkende 502-feil. Kl. 20:00 deaktiverte vi tunnelen, nettappene og synkroniseringsjobben, og stoppet overvåkertimeren.

Regelen vi bruker nå

• Pause en tjeneste ved å deaktivere den: sudo systemctl disable --now <unit>. Ta den i bruk igjen med sudo systemctl enable --now <unit>. Overvåkeren vår ser bare på aktiverte tjenester, så en deaktivert tjeneste lar den være i fred.
• Pause alt som kan starte den på nytt: tunnelen foran den og alle timere som overvåker den.
• Et kort stopp er en kappløp. Hvis du bare bruker stop, må du være ferdig før neste sjekk, som på maskinene våre kommer innen minutter.

To flere systemd-feller fra de samme månedene

• systemctl mask --runtime gjør ingenting for en enhetsfil i /etc/systemd/system. Enheter i /etc har forrang over maskeringen i /run, så kommandoen lykkes og tjenesten starter likevel. For å holde en tjeneste på vent bruker vi en drop-in med ConditionPathExists=!/etc/<name>.hold: så lenge den filen finnes, starter ikke tjenesten, verken ved oppstart eller manuelt.
• systemctl is-active kaller en kjørende oneshot-tjeneste inaktiv. Mens en Type=oneshot-tjeneste kjører, er tilstanden dens "activating", så is-active skriver ut det og returnerer 3. En løkke som while systemctl is-active --quiet job.service; do sleep 60; done, ment for å vente på en nattlig jobb, avsluttes umiddelbart. Les tilstanden i stedet: active, activating, reloading eller deactivating betyr alle at den fortsatt kjører.

Factory Floor overvåker aktiverte tjenester som ikke kjører. Som standard rapporterer den dem bare, og starter dem bare hvis du slår på det. Siden versjon 1.0.3 sier varselet også hvordan du kan pause en tjeneste med vilje, og runboken sier det samme.