Espressioni cron: i cinque campi, con esempi

I cinque campi

Ogni riga cron Unix standard inizia con gli stessi cinque campi, seguiti dal comando da eseguire.

* * * * *  command to run
| | | | |
| | | | +-- day of week  (0-7, 0 and 7 both mean Sunday, or SUN-SAT)
| | | +---- month        (1-12, or JAN-DEC)
| | +------ day of month (1-31)
| +-------- hour         (0-23)
+---------- minute       (0-59)

Un campo contiene una di quattro cose: un asterisco che significa qualsiasi valore, un numero singolo, un elenco, oppure un intervallo. Le ore usano un orologio a 24 ore senza AM o PM, quindi le 18 sono 18. Domenica è sia 0 che 7 perché sistemi diversi storicamente non erano d'accordo, e cron accetta entrambi.

Alcuni scheduler aggiungono campi. Quartz, usato da molti framework Java, mette un campo dei secondi all'inizio e aggiunge un anno opzionale alla fine, quindi un'espressione a sei o sette campi copiata da un riferimento Quartz non funzionerà in una crontab Linux. Controlla per quale variante stai scrivendo prima di copiare un'espressione da qualsiasi fonte.

I caratteri speciali

• * corrisponde a ogni valore del campo. * * * * * gira ogni minuto.
• , elenca dei valori. 0 8,13,20 * * * gira alle 08:00, 13:00 e 20:00.
• - definisce un intervallo. 0 9-17 * * * gira ogni ora piena dalle 09:00 alle 17:00.
• / definisce un passo all'interno di un intervallo. */15 * * * * gira ai minuti 0, 15, 30 e 45. Puoi combinarlo con un intervallo: 0 9-17/2 * * * gira alle 9, 11, 13, 15 e 17.
• Nomi. Da MON a SUN e da JAN a DEC funzionano negli ultimi due campi e si leggono meglio dei numeri. Non possono essere usati dentro un passo.

Altri quattro caratteri compaiono costantemente nei tutorial e non esistono nel cron standard. L per l'ultimo giorno, W per il giorno feriale più vicino, # per l'ennesimo giorno della settimana del mese e ? al posto di un asterisco sono estensioni di Quartz. Un'espressione come 0 0 L * * verrà rifiutata da una crontab Linux. Per eseguire qualcosa nell'ultimo giorno del mese lì, eseguilo ogni giorno e lascia decidere al comando:

0 0 * * * [ "$(date -d tomorrow +\%d)" = "01" ] && /usr/local/bin/month-end.sh

Nota le barre rovesciate in quella riga. Il segno di percentuale ha un significato speciale in una crontab, che è il quinto errore della lista sotto.

Cron accetta anche sei stringhe abbreviate al posto di tutti e cinque i campi: @yearly (scritto anche @annually), @monthly, @weekly, @daily (anche @midnight), @hourly, e @reboot, che gira una volta all'avvio di cron invece che secondo l'orologio. @reboot non è supportato ovunque.

Pianificazioni comuni

Errori che mettono il job all'ora sbagliata

1. Riempire entrambi i campi del giorno. Questo è quello che frega tutti. Quando il giorno del mese e il giorno della settimana sono entrambi impostati su qualcosa di diverso da un asterisco, cron esegue il job quando uno dei due corrisponde, non entrambi. 0 0 13 * FRI gira ogni giorno 13 e ogni venerdì, non solo venerdì 13.
2. Un passo che non divide l'intervallo. */7 * * * * scatta ai minuti 0, 7, 14, 21, 28, 35, 42, 49 e 56, poi riparte da 0. Il divario al passaggio dell'ora è di quattro minuti, non sette. La stessa trappola vale per */40 nel campo dei minuti e per qualsiasi passo che non sia un divisore di 60.
3. Mettere il passo nel campo sbagliato. */2 * * * * è ogni due minuti. 0 */2 * * * è ogni due ore. Dimenticare lo 0 iniziale trasforma un job orario in uno che gira 30 volte più spesso.
4. Dare per scontato l'ambiente. Cron fornisce al job un ambiente minimo, di solito poco più di PATH=/usr/bin:/bin e SHELL=/bin/sh. Uno script che funziona nella tua shell fallisce in cron perché chiama qualcosa in /usr/local/bin. Usa percorsi assoluti per il comando e al suo interno.
5. Un segno di percentuale senza escape. In una crontab, % viene trasformato in un a capo, e tutto ciò che segue il primo viene passato al comando come input standard. Un date +%Y-%m-%d dentro una riga di crontab va scritto date +\%Y-\%m-\%d.
6. Ignorare l'output. Tutto ciò che il job stampa viene inviato via email al proprietario della crontab, e su una macchina senza posta configurata viene scartato. Mandalo da qualche parte dove lo leggerai: 0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
7. Lasciare che le esecuzioni si sovrappongano. Cron avvia la successiva esecuzione secondo pianificazione, che l'ultima sia finita o no. Avvolgi i job lunghi in un lock: */5 * * * * flock -n /tmp/sync.lock /usr/local/bin/sync.sh
8. Dimenticare i cambi d'ora. Cron usa l'ora locale della macchina. Nei giorni in cui gli orologi cambiano, l'ora intorno alle 02:00 o non esiste o si presenta due volte, quindi un job pianificato al suo interno può essere saltato o eseguito due volte a seconda dell'implementazione di cron. Imposta i server su UTC, oppure pianifica fuori da quella finestra.
9. Digitare crontab -r. Cancella l'intera crontab senza chiedere conferma, ed è a un tasto di distanza da crontab -e. Tieni la crontab sotto controllo di versione e installala da un file.

Controllalo dall'esterno

Un'espressione che viene accettata non è la stessa cosa di un job che è girato davvero. Verifica entrambi, sulla macchina e poi dall'esterno.

Sulla macchina, conferma cosa è installato, cosa dice l'orologio, e se cron ha avviato il job:

crontab -l
timedatectl
grep CRON /var/log/syslog | tail -20
journalctl -u cron -u crond --since "2 hours ago"

La riga di log dimostra che cron ha lanciato il comando. Non dice nulla sul fatto che il comando sia riuscito, ed è per questo che conta il reindirizzamento verso un file di log citato tra gli errori sopra.

Poi controlla il risultato come farebbe un utente, dall'esterno del server. La maggior parte dei job pianificati esiste per cambiare qualcosa di osservabile: un feed che dovrebbe portare la data di oggi, una sitemap che dovrebbe essere stata riscritta, un'esportazione che dovrebbe essere comparsa. Richiedila e leggi gli header:

curl -sI https://example.com/exports/daily.json
curl -s https://example.com/health/last-run

L'header Last-Modified ti dice se il file è aggiornato, e lo fa senza accesso alla shell. Eseguire la stessa richiesta da più postazioni con il controllo HTTP separa un job che non è girato da una pagina che è in cache su un edge di una regione ed è obsoleta solo lì. Questa distinzione è invisibile con un singolo curl eseguito sul server stesso.

Sapere quando un job pianificato smette di girare

Un job cron che smette di girare non produce nulla da notare. Non c'è una pagina di errore né una richiesta fallita, quindi nulla genera un avviso a meno che qualcosa non stia osservando l'assenza. Ciò che monitori è l'effetto del job, non il job stesso: un file di stato che riscrive, un timestamp che pubblica, un endpoint che riporta l'ultima esecuzione riuscita. Un controllo pianificato su quell'endpoint trasforma un fallimento silenzioso in una notifica, e HostTracker le invia via email, SMS, chiamata vocale, Slack, Telegram e altro su 13 tipi di monitor. I meccanismi per configurarne uno sono nella guida al controllo HTTP, il resto delle guide di risoluzione dei problemi è nel cluster risolvere, e l'elenco completo dei tipi di controllo è sulla pagina delle funzionalità.