Dove vengono registrati gli errori cron?

Se ho impostato i cronlavori in modo errato, sembrano fallire silenziosamente. Dove devo cercare un registro degli errori per capire cosa è andato storto?

Come altri hanno sottolineato, cronti invierà via email l'output di qualsiasi programma che esegue (se c'è qualche output). Quindi, se non ottieni alcun output, ci sono sostanzialmente tre possibilità:

1. crond non è nemmeno possibile avviare una shell per l'esecuzione del programma o l'invio di e-mail
2. crond si sono verificati problemi con l'invio dell'output oppure la posta è andata persa.
3. il programma non ha prodotto alcun output (inclusi i messaggi di errore)

Il caso 1. è molto improbabile, ma qualcosa dovrebbe essere scritto nei registri cron. Cron ha una propria funzione syslog riservata, quindi dovresti dare un'occhiata /etc/syslog.conf(o il file equivalente nella tua distribuzione) per vedere dove cronvengono inviati i messaggi della struttura . Le destinazioni popolari includono /var/log/cron, /var/log/messagese /var/log/syslog.

Nel caso 2., dovresti ispezionare i log del demone mailer: i messaggi dal demone Cron di solito appaiono come da root@yourhost. È possibile utilizzare una MAILTO=...riga nel file crontab per fare in modo che cron invii e-mail a un indirizzo specifico, il che dovrebbe semplificare il grep dei log del demone mailer. Per esempio:

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

Nel caso 3., puoi verificare se il programma è stato effettivamente eseguito aggiungendo un altro comando di cui puoi facilmente verificare l'effetto: ad esempio,

00 15 * * * /a/command; touch /tmp/a_command_has_run

così puoi verificare se crondha effettivamente eseguito qualcosa guardando il mtime di /tmp/a_command_has_run.

È sempre possibile inviare in modo esplicito l'output del processo a un file di registro:

0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1

Tieni presente che questo sostituirà il comportamento della posta che è stato menzionato in precedenza, poiché crond stesso non riceverà alcun output dal lavoro. Se vuoi mantenere quel comportamento, dovresti guardare in tee (1).

Se non vedi le mail, potresti inviare spam alla tua azienda con gli errori che possono essere abbastanza fastidiosi per le persone che usano quell'account per il monitoraggio. Prova invece a inviare l'output a Syslog:

*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag

Quindi, attendere l'esecuzione di cronjob e cercare l'errore in / var / log / messages (o /var/log/user.log su alcuni sistemi).

Funziona benissimo per i messaggi di errore che sono lunghi solo 1-2 righe, come "yourcronjob: comando non trovato". Utilizza inoltre l'infrastruttura syslog esistente (Logrotation, syslogging centrale, Splunk, ecc.) Riduce inoltre lo spam delle e-mail alla radice.

Potrebbe non essere una buona soluzione se il tuo cronjob genera centinaia di righe di output.

La configurazione cron predefinita ti invierà una mail con l'output del tuo programma. In caso contrario, è possibile provare a racchiudere il programma in errore in uno script della shell che garantisce che il programma non fallisca e che sia possibile registrare ulteriormente l'output.

Questa è un'impostazione configurabile su alcune implementazioni cron.

Dovresti ricevere email da crondquando il lavoro non riesce o quando il lavoro restituisce un codice di uscita diverso da zero. Prova a digitare:

$ mailx

al prompt dei comandi.

mailx(1)è il programma base di lettura della posta su quasi tutti i sistemi Unixlike. È molto primitivo per gli standard moderni, ma puoi praticamente contare su di esso per essere sempre disponibile. Potrebbero essere disponibili altri agenti di posta migliori, ma ce ne sono abbastanza che non sai mai quale è installato su una macchina casuale che stai utilizzando.

Si noti che, a meno che non sia stato configurato il proprio sistema come server di posta elettronica Internet, questo sottosistema di posta viene utilizzato solo all'interno della macchina. Puoi inviare e-mail e ricevere da altri utenti sulla macchina, ma potresti non essere in grado di inviare e-mail al mondo, e certamente le e-mail provenienti dal mondo esterno non saranno in grado di arrivare alla tua macchina.

Cron registra le informazioni di base /var/log/messages, ma invia qualsiasi output del programma all'utente che invoca.

Mi sono imbattuto in questo thread alcuni anni fa sperimentando gli stessi problemi e proprio di recente ho trovato una soluzione ai casi di cui sopra Ricardo. La mancanza di un'e-mail è difficile da rilevare (come hai già detto) e certamente non vuoi spammare la tua e-mail root @ yourcompany. Se interessati, consulta deadmanssnitch.com. . Questo strumento sembra risolvere i casi di cui sopra. Sembra piuttosto semplice da usare: basta aggiungere il pezzetto di codice che lo strumento ti dà al tuo cronjob. Se il lavoro non viene eseguito su un interno specificato, verrai avvisato. Se il tuo lavoro riprende a funzionare, verrai avvisato.

Lo uso vixie-cron, quindi non so se questo vale per tutto. Ma ho un dead.letterfile che contiene tutto l'output del lavoro.

Nella mia /root/cartella ho quello crons.cronche ho impostato come mio crontab eseguendo crontab /root/crons.cron. dead.letterverrà creato /root/anche in.

Modifica Ho appena Google dead.letter, ed è una posta non consegnabile. Apparentemente non ha nulla a che fare con cron. Se non hai configurato correttamente la posta (come me), avrai il file.

Per i neofiti, questo potrebbe essere un problema per il debug. Assicurarsi di non scambiare i valori dei minuti e delle ore. Prima arriva il minuto, poi l'ora. Quando fornisci valori inferiori a 12 per ciascuno, li accetterà ma potrebbe non funzionare come previsto o affatto.