Monitorare un cron Linux

Il problema classico con cron : quando un job fallisce o smette di partire, nessuno viene avvisato. La mail locale di cron finisce in/var/mail che nessuno legge. Risultato: un backup silenziosamente rotto da 3 settimane, che scopri il giorno in cui ti serve davvero.

Perché i cron falliscono in silenzio

• Il server si è riavviato e crond non è ripartito.
• Il PATH del cron è diverso da quello della shell interattiva → comando non trovato.
• Il disco è pieno, oppure un lock (flock) blocca l'esecuzione.
• Lo script va in crash ma restituisce exit code 0, quindi «tutto a posto».

Cerchi la riga di crontab vera e propria: flag di curl, escape del %, anti-sovrapposizione? Vai alla guida cron ogni 5 minuti.

La soluzione: un dead man's switch

Invece di monitorare il server, chiedi al cron di segnalare che ha girato. Se non segnala nulla all'orario previsto, è proprio lui il problema. Crea un check su Cron-Ping, recupera la tua URL e aggiungi un curl :

# prima: non sai mai se gira
0 2 * * * /opt/backup.sh

# dopo: ping solo se lo script va a buon fine
0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token>

Distinguere successo e fallimento

0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token> || curl -fsS https://cron-ping.com/p/<token>/fail

Se backup.sh fallisce, chiamiamo /fail e ricevi subito un alert, senza aspettare il periodo di tolleranza.

Verificare che cron giri davvero

systemctl status cron      # Debian/Ubuntu
systemctl status crond     # RHEL/CentOS
grep CRON /var/log/syslog