Cosa fa davvero questa espressione cron?

Il cron standard si legge da sinistra a destra: minuto, ora, giorno del mese, mese, giorno della settimana. Alcuni scheduler — questo strumento compreso — accettano un campo iniziale opzionale per i secondi, portando il totale a sei. Ogni campo accetta un numero, una lista separata da virgole, un intervallo (1-5), un passo (*/15) o una combinazione (10-50/10). I campi mese e giorno della settimana accettano anche i nomi: JAN-DEC e SUN-SAT (oppure 0-7, dove sia 0 sia 7 indicano la domenica).

* significa «qualsiasi valore» per quel campo — * * * * * scatta ogni minuto. */15 significa «ogni 15° valore a partire dal minimo del campo» — per i minuti sono :00, :15, :30, :45.

Il cron semplice — quello che sta nella tua crontab — ha 5 campi, con un limite inferiore di un'esecuzione al minuto. Alcuni strumenti (questo, più cose come node-cron) accettano un sesto campo iniziale per i secondi, che è l'unico modo di esprimere «ogni 10 secondi» nella sintassi cron. I due formati si confondono facilmente: 0 30 2 * * * sembra voler dire le 2:30, ma con sei campi il primo 0 sono i secondi e la pianificazione scatta in realtà alle 02:30:00 — che, scritta come cron a 5 campi, sarebbe 30 2 * * *. Sbagliare a contare i campi è in assoluto il modo più comune di pianificare il job giusto all'ora sbagliata.

Le scorciatoie con @ — @hourly, @daily, @weekly, @monthly, @yearly (@annually e @midnight sono alias) — si espandono in espressioni cron standard fisse e si comportano in modo identico. @reboot è un altro paio di maniche; vedi più sotto.

0 0 13 * 5 si legge come «il 13, se è un venerdì» — venerdì 13. Non è così. Il cron standard tratta giorno del mese e giorno della settimana come un OR ogni volta che entrambi sono ristretti: il job scatta il 13 di ogni mese e ogni venerdì, il che per la maggior parte dei mesi significa cinque o sei esecuzioni invece dell'unica che avevi in mente.

Il morso arriva solo quando entrambi i campi sono ristretti insieme. 0 0 13 * * (ogni 13 del mese, con il giorno della settimana lasciato a *) significa esattamente quello che sembra, e lo stesso vale per 0 0 * * 5 (ogni venerdì). È la combinazione a passare in silenzio da AND a OR, ed è una delle sorprese più antiche di cron — POSIX la specifica, ogni implementazione cron importante la segue, e continua a fregare chi ha imparato a programmare dopo che gran parte delle specifiche POSIX era già scritta.

Cron pianifica in ora locale, e l'ora locale non è continua attraverso un cambio dell'ora legale. Due volte l'anno, da qualche parte, un orologio salta un'ora oppure ne ripete una — e un job pianificato dentro quell'ora deve pur fare qualcosa, perché «eseguilo lo stesso» non ha un significato univoco.

Quando le lancette vanno avanti, gli orari dell'ora saltata non esistono. Un job impostato alle 02:30 nel giorno in cui Europe/Paris salta dalle 02:00 alle 03:00 non ha semplicemente nessuna 02:30 in cui girare — questo strumento riporta quell'esecuzione come saltata invece di spostarla in silenzio all'01:30 o alle 03:30, perché entrambe le ipotesi sarebbero sbagliate almeno tanto spesso quanto giuste.

Quando le lancette tornano indietro, gli orari dell'ora ripetuta capitano due volte. Questo strumento segue la convenzione che usa ogni implementazione cron di nostra conoscenza: scatta una volta sola, alla prima occorrenza, non due.

La soluzione pratica è noiosa ma affidabile: pianifica i job di manutenzione fuori dalla finestra 00:00-04:00, dove la maggior parte delle regioni colloca il proprio cambio dell'ora legale, oppure fai girare la tua infrastruttura in UTC da capo a fondo, dove tutta questa sezione non si applica.

@reboot gira una volta sola, all'avvio della macchina — cron stesso non garantisce nulla oltre a questo, e non ha alcun concetto di «prossima esecuzione» per esso, perché una prossima esecuzione non c'è. Il che lo rende poco adatto al solito schema di monitoraggio «avvisami se questo non gira quando previsto»: non c'è pianificazione, quindi non c'è nulla con cui confrontare un silenzio. Se un job @reboot conta davvero — ripristinare uno stato dopo un crash, per dire — la cosa che vale la pena sorvegliare di solito è lo stato che ripristina, non l'evento di avvio in sé.

Serve un account?

No. Non c'è registrazione e non c'è un rate limit degno di nota, perché qui niente chiama un server — il parsing e il calcolo della prossima esecuzione avvengono entrambi nel tuo browser.

Conservate le espressioni che provo?

No. Nulla di ciò che digiti viene inviato da qualche parte, quindi non c'è niente da conservare e niente da chiederci di cancellare.

Perché a volte mostra meno di 8 esecuzioni?

Una manciata di espressioni descrive una pianificazione che scatta di rado, o mai. 0 0 31 2 * (31 febbraio) non corrisponde a nessuna data reale e restituisce zero esecuzioni. 0 0 29 2 * (29 febbraio) corrisponde solo agli anni bisestili, quindi possono servire diversi anni di ricerca prima che salti fuori la prossima esecuzione.

Quali estensioni cron non sono supportate?

Gli extra in stile Quartz che alcuni scheduler aggiungono sopra il cron POSIX: L (ultimo giorno), W (giorno feriale più vicino), # (ennesimo giorno della settimana del mese) e ? (nessun valore specifico). Questo strumento li segnala esplicitamente invece di interpretarli male in silenzio come qualcos'altro.

Il mio server usa un fuso orario diverso da quello scelto qui — è un problema?

Sì, e vale la pena verificarlo. Su una tipica macchina Linux cron gira nel fuso orario configurato nel sistema, non necessariamente UTC e non necessariamente il tuo. Scegli il fuso in cui gira davvero la crontab del tuo job, non quello in cui sei seduto tu, altrimenti gli orari mostrati da questo strumento non corrisponderanno alla realtà.