Cron job: best practice per task ricorrenti

cron e lo scheduler classico Unix: semplice, affidabile, presente da decenni. Scrivere cron job in modo professionale fa la differenza tra task che funzionano per anni e script che falliscono silenziosamente. Vediamo le best practice essenziali.

Sintassi essenziale

La sintassi e minuto ora giorno-mese mese giorno-settimana comando. Esempio: 30 3 * * * /usr/local/bin/backup.sh esegue lo script ogni giorno alle 3:30. Modi speciali: @daily, @hourly, @reboot. Crontab utenti si modificano con crontab -e; crontab di sistema in /etc/cron.d/ o /etc/crontab con campo utente aggiuntivo.

Locking per evitare sovrapposizioni

Un task lento che si accavalla con se stesso e una causa frequente di disastri (carico, race condition, corruzione). Usa flock: flock -n /tmp/myjob.lock /usr/local/bin/myjob.sh. Il flag -n evita di accodare: se il lock e occupato, esce immediatamente. In alternativa setlock o uno script di guardia con PID file.

Logging e error handling

Per default cron invia stdout/stderr a email. Imposta MAILTO in crontab a un'indirizzo monitorato. Meglio: redirigi a un log e usa un wrapper che notifica solo in caso di errore. Esempio: 30 3 * * * /opt/jobs/backup.sh >> /var/log/backup.log 2>&1 || /opt/jobs/notify-error.sh "backup failed".

Procedura passo-passo

1. Scrivi lo script con set -euo pipefail all'inizio (bash).
2. Includi un trap ERR per logging strutturato.
3. Definisci PATH all'inizio dello script: cron ha PATH minimale.
4. Usa percorsi assoluti per binari e file.
5. Avvolgi in flock per evitare sovrapposizioni.
6. Redirigi stdout/stderr a log con timestamp.
7. Aggiungi notifica in caso di errore o assenza del log atteso.
8. Pianifica una "heartbeat" check con healthchecks.io o servizi simili.
9. Documenta il job in /etc/cron.d/ con commenti.

Monitoraggio dei cron

Un cron job che fallisce silenziosamente e peggio di un job mancante: pensi sia ok ma non lo e. Usa dead man s switch: il job pinga un'endpoint dopo l'esecuzione. Se il ping manca, ricevi alert. Servizi: healthchecks.io, cronitor.io, o self-hosted healthchecks.

Errori comuni e come risolverli

• PATH non impostato: cron non vede binari in /usr/local/bin; definisci PATH.
• Ambiente diverso da shell: cron non legge ~/.bashrc; esporta variabili nello script.
• Permessi e proprietario errati: lo script deve essere eseguibile dall'utente cron.
• Charset/locale: imposta LANG e LC_ALL se lo script li richiede.
• Mancanza di lock: job lenti si accavallano causando carichi anomali.

systemd timer come alternativa

I timer systemd offrono: logging in journal, dipendenze esplicite, on-failure handlers, calendar specs più espressivi. Per nuovi sistemi e spesso una scelta migliore. Cron resta insostituibile per la sua diffusione e semplicità.

Domande frequenti

D: Come testo un cron senza aspettare l'ora?
R: Esegui manualmente lo script come l'utente cron e verifica i log.

D: Posso passare argomenti?
R: Si, basta concatenare nello script o nella riga cron.

D: anacron e diverso?
R: Si, e per sistemi spenti regolarmente (laptop): recupera task persi.

Approfondimento tecnico: cron-anachronisms e best practice

Molti errori cron storici derivano dal suo ambiente minimale. PATH non include /usr/local/bin per default. SHELL e sh, non bash: usa shebang esplicito negli script. Locale e C: imposta LANG e LC_ALL se servono caratteri non-ASCII. HOME potrebbe essere indefinito: settalo se lo script lo richiede.

Il output buffering e una causa di "mail non arrivate": se lo script termina con codice 0 ma scrive a stderr, cron invia mail; per silenziare casi attesi usa 2>&1 | grep -v "warning ignorabile" >> /var/log/job.log. La best practice attuale: log strutturato JSON via logger command a journald, e monitoring via dead man s switch (healthchecks.io ping all'inizio e alla fine).

Scenari d'uso reali

Un backup quotidiano con flock + ping a healthchecks.io: se manca il ping, alert telegram entro 5 minuti.

Un job di reindex Elasticsearch con lock per evitare sovrapposizioni durante riavvii cluster.

Un cron orario di sync con database remoto in retry intelligent: 3 tentativi con backoff esponenziale prima di alert.

Checklist operativa cron

• PATH esplicito all'inizio dello script.
• Lock con flock per evitare sovrapposizioni.
• Output redirezionato e logging strutturato.
• Alert su errore o assenza heartbeat.
• Test manuale prima di pianificare.
• Documentazione di ogni job in /etc/cron.d/.
• Healthcheck con dead man s switch.

Risorse e riferimenti

man 5 crontab. healthchecks.io, cronitor.io per dead man s switch. Per scheduling avanzato: systemd timer, Kubernetes CronJob, Jenkins schedules. crontab.guru per generare/validare espressioni cron.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su cron job richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.