Om 03:30 vannacht liep mijn genealogie-pipeline en om 03:30 vannacht stierf mijn genealogie-pipeline. Het vreemde: het ding dat hij moest beschermen — de backup — kwam er perfect uit. Drieënnegentig megabyte, gecomprimeerd, leesbaar, met de actieve database erin. Alles wat het script moest opleveren stond op schijf. En toch zijn de vier stappen daarna nooit uitgevoerd.
Allemaal door één regel uitvoer die zegt dat er niets aan de hand is.
tar zegt: “het is gelukt, maar er bewoog iets”
Het script maakt een archief van de datamap terwijl de applicatie er nog in schrijft. Dat is normaal, en tar heeft daar een eigen exitcode voor: 1 betekent “ik ben klaar, maar er veranderde een bestand terwijl ik las.” Dat is een waarschuwing, geen fout. Vanaf 2 is het menens.
Mijn script begint met set -euo pipefail, en dat is voor bijna alles wat ik schrijf de juiste standaard. Maar set -e maakt geen onderscheid tussen “waarschuwing” en “ramp”. Het ziet een exitcode die niet nul is en stopt. De shell behandelde een waarschuwing dus als vonnis, kapte de run af op regel 34 en kwam nooit bij de pipeline: geen index, geen vondsten, geen dossiers, geen GEDCOM-export.
Het nachtlog eindigt na vijf regels: de dump, dan tar: .: file changed as we read it. Geen “Klaar”, geen foutmelding, geen stack trace. Alleen een stop.
Het dure lukte, het goedkope viel weg
Dat is het deel dat me het meest stoort. De backup — de trage, zware, belangrijke stap — werkte. De vier stappen erachter, die seconden kosten en van niets afhankelijk zijn dat misging, werden stilzwijgend overgeslagen. Ik verloor een nacht verse index, duizend-en-negen dossiers en een GEDCOM-export, niet door een dataprobleem, maar omdat een bewaker te grof was om een getal te lezen.
En het is intermittent. Ik telde de nachtlogs: één treffer op tweeëndertig. Dat is de vervelendste soort fout — hij treedt niet op commando op, dus hij verschuilt zich achter “gisteren werkte het toch”. Mijn eerste synthetische reproductie triggerde hem niet eens; pas de tweede poging, met de timing goed, liet dezelfde exit 1 zien bij een volstrekt leesbaar archief.
Lees de exitcode vóór de shell dat doet
De oplossing is klein en het is geen lapmiddel. Zet errexit uit rond precies die ene aanroep, vang de code zelf op en beslis: twee of hoger betekent dat het archief stuk is en weg moet; één betekent waarschuwen en doorgaan; nul is gewoon goed. Lees daarna het archief terug en eis dat de actieve database er echt in zit, vóór je de dump opruimt.
Vanmorgen om 08:14 liep hij en slaagde: 1161 entries, de actieve database aanwezig, en de hele pipeline erachter — 1009 dossiers, 15 tak-indexen, een GEDCOM van 220 KB met 915 personen. Dezelfde data, vijf uur later, omdat een waarschuwing als fout was gelezen.
De regel die ik eruit houd: een pipeline die een externe tool aanroept, moet de exitcodes van die tool interpreteren vóór set -e dat doet. En opruimen hoort in een trap, niet op de regel ná de stap die kan afbreken — de mijne liet een database-dump van acht megabyte liggen, precies omdat de regel die hem verwijdert nooit aan de beurt kwam.
Daarom mijn vraag: hoeveel van jouw automatiseringen behandelen “niet nul” als één enkele toestand? De mijne deed dat, in een script dat ik tientallen keren had gelezen, en het kostte me een nacht zonder één foutmelding om op te wijzen.
Wat vond je van dit bericht?
