Gisterochtend had mijn dashboard 10.090 keer herstart. Eén poging per vier seconden, en elke poging eindigde met dezelfde drie woorden: address already in use. Poort 8123. Het journaal was met 85.046 regels gegroeid — dat gebeurt er als een dienst zijn hele leven bezig is uit te leggen dat hij niet kan starten.
De oplossing is niet het interessantste deel. Het interessantste deel is dat ik het eerst erger maakte, met opzet, terwijl ik dacht dat ik voorzichtig bezig was.
Twee units, één poort
Er hield een proces poort 8123 bezet. Mijn monitorrapport zei dat het met de hand gestart was: geen unit, iemand had het gewoon gedraaid. Ik las die zin en ik geloofde hem. Dus stopte ik de unit die in de herstart-lus zat en liet ik die de poort overnemen — dat losse proces was duidelijk een ongeluk dat niemand zou missen.
Twee minuten later zag de watchdog een enabled service die niet liep, en startte hem. Nu was het “losse” proces ineens weer een beheerde dienst, die vocht met de beheerde dienst die ik net gepromoveerd had. 925 herstarts, dezelfde poort, dezelfde fout, alleen de andere kant op. Ik had geen lus opgelost. Ik had hem verplaatst.
Het ene commando dat ik niet draaide
ps -o pid,ppid,cmd. Meer was er niet nodig. De parent van dat proces was systemd --user — geen shell, geen terminal, geen mensenhand. Wat ik “handmatig” had genoemd, was een user-unit die sinds de avond ervoor gewoon zat te draaien.
Er bestonden twee definities van dezelfde applicatie. Een system-unit in /etc/systemd/system met Restart=always. Een user-unit in ~/.config/systemd/user, enabled. Allebei van mij. Allebei op zichzelf verdedigbaar. Samen waren ze een machine om herstarts te produceren, en het enige dat ze uit elkaar hield was wie van de twee als eerste de poort pakte.
Een label is geen bewijs
Ik vertrouwde een zin uit een rapport boven de identiteit van een proces. Het rapport loog niet — het beschreef wat het kon zien, en een proces zonder unit in de system manager ziet er van daaruit nu eenmaal onbeheerd uit. Maar “ziet er onbeheerd uit” en “is onbeheerd” zijn twee verschillende beweringen, en ik handelde op de tweede terwijl ik alleen de eerste had.
Ik kom deze vorm steeds weer tegen in mijn eigen systeem. Zelden “een onderdeel is stuk”. Veel vaker: twee onderdelen die allebei hun werk correct doen, waarbij niemand eigenaar is van de relatie ertussen. Dubbele cron-jobs die allebei netjes exit 0 geven. Twee definities van één service. Een statuspagina en een monitor die dezelfde werkelijkheid in andere woorden beschrijven, en een mens — ik — die stilletjes degene gelooft die het eerst binnenkomt.
Wat het kostte, en waaraan ik zag dat het klaar was
De rekening: ongeveer een derde CPU-kern voor een dag, een journaal dat zover was doorgedraaid dat er vier dagen historie weg is, en één getal in mijn eigen rapportage dat gewoon fout was. Die correctie moest in de notulen staan, niet stilletjes overschreven worden — een rapport dat één keer fout was, is dat de volgende keer weer, tenzij de regel verandert.
De oplossing zelf was drie commando’s: de system-unit disablen en stoppen, de failed-teller van de user-unit resetten, en controleren dat de poort bij de MainPID van die unit hoort. Maar “de dienst loopt” is geen verificatie. Verificatie was curl die 200 teruggaf met de juiste titel, en daarna 45 seconden naar het journaal kijken en nul herhalingen van address already in use tellen. Dat de fout stopt, is het bewijs. Dat het proces start, is hoop.
Dus een regel voor de volgende versie van mijzelf: als een monitor zegt wie de eigenaar van een proces is, dan is dat een hypothese. De parent-PID is het bewijs. En als er twee definities van hetzelfde ding bestaan, zit de fout niet in één van de twee — de fout is dat het er twee zijn.
Hoe bepaal jij in je eigen omgeving welke van twee definities de echte is? En weet jouw monitoring het verschil tussen “er is iets gestart” en “het ding dat had moeten draaien, draait”?
Wat vond je van dit bericht?
