Vår bevakningsprocess startade om de tjänster vi hade stoppat med avsikt

Drift2026-10-31

En av våra bevakningsprocesser startar alla våra tjänster som är aktiverade men inte körda. Två gånger i oktober startade den tjänster vi hade stoppat med avsikt. Andra gången fick besökare på en av våra webbplatser felmeddelanden i cirka 45 minuter.

Varför den bevakningsprocessen finns

En tjänst som avslutas korrekt när den får SIGTERM, till exempel för att något dödade den vid namn, är inte "failed" enligt systemd. Restart=on-failure startar inte om den, och systemctl --failed listar inte den. Den förblir nere tills någon råkar märka det. Så bevakningsprocessen letar efter tjänster som är aktiverade men inte körda, och startar dem.

Problemet är att en tjänst du stoppade manuellt ser exakt likadan ut.

Första gången

Den 7 oktober stoppade vi en videobearbetare med systemctl stop klockan 12:47 för att redigera dess jobbkö. Klockan 12:55 kördes den igen: bevakningsprocessen hade startat den.

Andra gången

Den 21 oktober behövde vi minnet på den maskin som också servar två av våra webbplatser för ett modelltest. Ett skript stoppade webbplatsernas webbappar, ett synkroniseringsjobb och en databascontainer, återigen med systemctl stop. Cirka fem minuter senare startade en timer som övervakar webbplatserna, och klockan 19:14 bevakningsprocessen, tillbaka tunneln och webbapparna.

Tunneln tog emot trafik igen, men webbapparna kunde inte svara: modellen under test höll 114 GiB av maskinens minne. Från cirka 19:14 till 20:00 fick vissa besökare 502-fel. Klockan 20:00 inaktiverade vi tunneln, webbapparna och synkroniseringsjobbet, och stoppade övervakningstimern.

Regeln vi använder nu

• Pausa en tjänst genom att inaktivera den: sudo systemctl disable --now <unit>. Starta den igen med sudo systemctl enable --now <unit>. Vår bevakningsprocess tittar bara på aktiverade tjänster, så en inaktiverad lämnas ifred.
• Pausa allt som kan starta om den: tunneln framför den och alla timrar som övervakar den.
• En kort stoppning är en kapplöpning. Om du bara använder stop, avsluta innan nästa kontroll, som på våra maskiner kommer inom några minuter.

Två fler systemd-fällor från samma månader

• systemctl mask --runtime gör ingenting för en enhetsfil i /etc/systemd/system. Enheter i /etc har företräde framför den tillfälliga maskeringen i /run, så kommandot lyckas och tjänsten startar ändå. För att hålla en tjänst på paus använder vi en drop-in med ConditionPathExists=!/etc/<name>.hold: så länge den filen finns startas inte tjänsten, varken vid uppstart eller manuellt.
• systemctl is-active kallar en körande oneshot-tjänst för inactive. Medan en Type=oneshot-tjänst körs är dess tillstånd "activating", så is-active skriver ut det och returnerar 3. En loop som while systemctl is-active --quiet job.service; do sleep 60; done, avsedd att vänta på ett nattligt jobb, avslutas direkt. Läs tillståndet istället: active, activating, reloading eller deactivating betyder alla att den fortfarande pågår.

Factory Floor bevakar aktiverade tjänster som inte körs. Som standard rapporterar den dem bara, och startar dem bara om du slår på det. Sedan version 1.0.3 säger dess varning också hur du pausar en tjänst avsiktligt, och dess runbook säger samma sak.