WatchDer er en særlig slags frustration i et cron-job, der ikke vil køre: det virker perfekt, når du taster kommandoen i hånden, og gør så intet på det planlagte tidspunkt. Ingen fejl, intet output, intet spor. Scriptet er fint — problemet er næsten altid afstanden mellem det bekvemme miljø, du kører ting i, og den nøgne, afpillede verden, cron faktisk lever i. Når du først forstår den afstand, holder fejlsøgning af et tavst cron-job op med at være gætteri og bliver en kort, pålidelig tjekliste.
Tjek tidsplanen først
Før du mistænker noget smart, så mistænk tidsplanen — det er den mest almindelige synder med stor margin. Indsæt dit cron-udtryk i en parser, og bekræft, at det faktisk betyder, hvad du tror; “0 0 * * 0” er ugentligt om søndagen, ikke dagligt, og netop den fejllæsning står bag et overraskende antal “det kørte ikke”-meldinger.
Tjek så to ting, folk glemmer. Cron bruger serverens tidszone, som ofte er UTC frem for din lokale tid, så et job, du forventer kl. 9, måske kører på det, du tænker på som midt om natten. Og bekræft, at selve cron-tjenesten overhovedet kører — et hurtigt systemctl status cron udelukker det pinlige tilfælde, hvor hele planlæggeren er stoppet.
Stier, rettigheder og miljø
Her er kernen: cron kører ikke med din shell. Den kører med et minimalt miljø, der har næsten ingen af de bekvemmeligheder, du tager for givet, og det er derfor, et script, der virker fejlfrit i hånden, kan gøre intet under cron.
De sædvanlige syndere er alle variationer over det tema. Scriptet kalder en kommando, der ikke er på crons nøgne PATH. Det bruger en relativ sti, der kun virker fra dit arbejdskatalog. Det er ikke markeret eksekverbart. Eller det afhænger stille af miljøvariabler sat i din .bashrc — database-URL'er, API-nøgler — som cron aldrig loader. Løsningerne er lige så ensartede: brug absolutte stier overalt, sæt PATH eksplicit øverst i scriptet, og indlæs det miljø, du har brug for, frem for at gå ud fra, det er der.
Læs loggen
Hold op med at gætte, og lad systemet fortælle dig, hvad der skete. Cron logger til systemloggen, så tjek /var/log/syslog eller journalctl -u cron for at besvare det første spørgsmål: kørte jobbet overhovedet? Det ene svar deler problemet rent i to.
Er der ingen log-linje på det forventede tidspunkt, ligger problemet opstrøms — tidsplanen eller cron-tjenesten — ikke i dit script, så gå tilbage til trin ét. Kørte det, men arbejdet skete ikke, så kørte scriptet og fejlede i stilhed. Omdirigér dets eget output til en fil med >> /sti/til/log 2>&1, så næste kørsel fanger den faktiske fejl i stedet for at smide den væk. Den omdirigering gør en usynlig fejl til en læsbar.
Sådan ved du det i samme øjeblik, det fejler, med WatchControl
Selv når du har fikset dagens problem, er der et dybere, tjeklisten ikke kan løse: et cron-job, der har kørt perfekt i måneder, vil før eller siden fejle i stilhed alligevel. En server crasher, et deploy ændrer en sti, en disk fyldes op — og fordi intet poller et cron-job, fortæller intet dig det. Du opdager det, når du har brug for det resultat, der ikke er der.
Heartbeat-overvågning er svaret på det, og det er den ene brik, der beskytter dig fremadrettet frem for bare at forklare fortiden. Dit job pinger en unik URL, når det afslutter korrekt; hvis det ping ikke når frem efter tidsplanen, bliver du alarmeret. I WatchControl opretter du en heartbeat-monitor og tilføjer én curl-linje til slutningen af dit job — ingen agent, gratis at starte — og fra da af bliver et cron-job, der stopper, til en notifikation, ikke en grim overraskelse.