Come registrare i lavori cron?

Voglio sapere come posso vedere esattamente cosa stanno facendo i lavori cron su ogni esecuzione. Dove si trovano i file di registro? Oppure posso inviare l'output alla mia e-mail? Ho impostato l'indirizzo e-mail per inviare il registro quando viene eseguito il processo cron ma non ho ancora ricevuto nulla.

* * * * * myjob.sh >> /var/log/myjob.log 2>&1

registrerà tutto l'output del processo cron su /var/log/myjob.log

È possibile utilizzare mailper inviare e-mail. La maggior parte dei sistemi invierà l' cronoutput di lavoro non gestito via e-mail a root o all'utente corrispondente.

Per impostazione predefinita cron registra in / var / log / syslog in modo da poter vedere le voci relative a cron usando:

grep CRON /var/log/syslog

/ubuntu/56683/where-is-the-cron-crontab-log

Ecco il mio codice:

* * * * * your_script_fullpath >> your_log_path 2>&1

Esistono almeno tre diversi tipi di registrazione:

1. La registrazione PRIMA che il programma venga eseguito, che registra solo SE il cronjob TRIED per eseguire il comando. Quello si trova in / var / log / syslog, come già accennato da @Matthew Lock.

2. La registrazione degli errori DOPO che il programma ha tentato di essere eseguito, che può essere inviato a un'email o a un file, come indicato da @Spliffster. Preferisco accedere a un file, perché con l'email THEN hai una NUOVA fonte di problemi, e il suo controllo se l'invio e la ricezione dell'email funziona perfettamente. A volte lo è, a volte no. Ad esempio, in una semplice macchina desktop comune in cui non sei interessato a configurare un smtp, a volte preferirai accedere a un file:

    * * * *  COMMAND_ABSOLUTE_PATH > /ABSOLUTE_PATH_TO_LOG 2>&1
   

   • Vorrei anche prendere in considerazione la verifica delle autorizzazioni di / ABSOLUTE_PATH_TO_LOG ed eseguire il comando dalle autorizzazioni dell'utente. Solo per verifica, mentre si verifica se potrebbe essere una potenziale fonte di problemi.
3. La registrazione del programma stesso, con la propria gestione degli errori e la registrazione per scopi di monitoraggio.

Ci sono alcune fonti comuni di problemi con cronjobs: * Il PERCORSO ASSOLUTO del binario da eseguire. Quando lo esegui dalla tua shell, potrebbe funzionare, ma il processo cron sembra usare un altro ambiente, e quindi non trova sempre i binari se non usi il percorso assoluto. * Le librerie utilizzate da un file binario. È più o meno lo stesso punto precedente, ma assicurati che, semplicemente inserendo il NAME del comando, si riferisca esattamente al binario che utilizza la stessa libreria, o meglio, controlla se il binario a cui ti riferisci con il percorso assoluto è lo stesso a cui ti riferisci quando usi direttamente la console. I file binari possono essere trovati utilizzando il comando Locate, ad esempio:

$locate python

Assicurati che il binario a cui farai riferimento sia lo stesso binario che stai chiamando nella tua shell, o semplicemente esegui nuovamente il test nella tua shell usando il percorso assoluto che prevedi di inserire nel cronjob.

• Un'altra fonte comune di problemi è la sintassi del cronjob. Ricorda che ci sono caratteri speciali che puoi usare per elenchi (virgole), per definire intervalli (trattini -), per definire l'incremento di intervalli (barre), ecc. Dai un'occhiata: http://www.softpanorama.org/Utilities/ cron.shtml

Su Ubuntu puoi abilitare un cron.logfile per contenere solo le voci CRON.

Rimuovi il commento dalla riga menzionata cronnel /etc/rsyslog.d/50-default.conffile:

#  Default rules for rsyslog.
#

#                       For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                          /var/log/cron.log

Salvare e chiudere il file e quindi riavviare il rsyslogservizio:

sudo systemctl restart rsyslog

Ora puoi vedere le voci del registro cron nel suo file:

sudo tail -f /var/log/cron.log

Output di esempio:

Jul 18 07:05:01 machine-host-name CRON[13638]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

Tuttavia, non verranno visualizzate ulteriori informazioni su quali script sono stati effettivamente eseguiti all'interno /etc/cron.dailyo /etc/cron.hourly, a meno che tali script non indirizzino l'output a cron.log (o forse ad altri file di registro).

Se si desidera verificare se un crontab è in esecuzione e non è necessario cercarlo in , cron.logoppure syslogcreare un crontab che reindirizza l'output su un file di registro di propria scelta, ad esempio:

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log 2>&1

Passaggi presi da: https://www.cyberciti.biz/faq/howto-create-cron-log-file-to-log-crontab-logs-in-ubuntu-linux/

cron invia già l'output standard e l'errore standard di ogni processo che esegue per posta al proprietario del processo cron.

È possibile utilizzare MAILTO=recipientnel crontabfile per inviare le e-mail a un altro account.

Affinché ciò funzioni, è necessario che la posta funzioni correttamente. Il recapito a una casella di posta locale di solito non è un problema (in effetti, è probabile che ls -l "$MAIL"ti accorga che ne hai già ricevuto qualcuno), ma per ottenerlo fuori dalla scatola e su Internet richiede l'MTA (Postfix, Sendmail, che cosa hai) per essere correttamente configurato per connettersi al mondo.

Se non viene generato alcun output, non verrà generata alcuna e-mail.

Una disposizione comune è il reindirizzamento dell'output su un file, nel qual caso ovviamente il demone cron non vedrà il lavoro restituire alcun output. Una variante è reindirizzare l'output standard su un file (o scrivere lo script in modo che non stampi mai nulla - forse memorizza invece i risultati in un database o esegue attività di manutenzione che semplicemente non generano nulla?) E riceve un'e-mail solo se presente è un messaggio di errore.

Per reindirizzare entrambi i flussi di output, la sintassi è

42 17 * * * script >>stdout.log 2>>stderr.log

Notate come aggiungiamo (doppio >>) invece di sovrascrivere, in modo che l'output di qualsiasi lavoro precedente non venga sostituito dal successivo.

Come suggerito in molte risposte qui, è possibile inviare entrambi i flussi di output a un singolo file; sostituire il secondo reindirizzamento con 2>&1per dire "l'errore standard dovrebbe andare ovunque stia andando l'output standard". (Ma non approvo in modo particolare questa pratica. Ha senso soprattutto se non ti aspetti davvero qualcosa dall'output standard, ma potresti aver trascurato qualcosa, forse proveniente da uno strumento esterno chiamato dal tuo script.)

croni lavori vengono eseguiti nella directory principale, quindi i nomi di file relativi devono essere relativi a quello. Se vuoi scrivere al di fuori della tua home directory, ovviamente devi assicurarti separatamente di avere accesso in scrittura a quel file di destinazione.

Un antipattern comune è reindirizzare tutto a /dev/null(e quindi chiedere a Stack Overflow di aiutarti a capire cosa è andato storto quando qualcosa non funziona; ma non possiamo nemmeno vedere l'output perso!)

Dall'interno dello script, assicurati di mantenere separati l'output regolare (risultati effettivi, idealmente in forma leggibile da una macchina) e la diagnostica (solitamente formattata per un lettore umano). In uno script di shell,

echo "$results"  # regular results go to stdout
echo "$0: something went wrong" >&2

Alcune piattaforme (e ad esempio GNU Awk) consentono di utilizzare il nome del file /dev/stderrper i messaggi di errore, ma questo non è correttamente portabile; in Perl warne diestampa con errore standard; in Python, scrivi sys.stderro usa logging; in Ruby, prova $stderr.puts. Notare anche come i messaggi di errore dovrebbero includere il nome dello script che ha prodotto il messaggio diagnostico.

Nel caso in cui tu stia eseguendo un comando con sudo, non lo consentirà. Il Sudo ha bisogno di un tty.

Se desideri comunque controllare i tuoi lavori cron, devi fornire un account e-mail valido quando imposti i lavori Cron in cPanel.

Quando specifichi un indirizzo email valido riceverai l'output del cron job che viene eseguito. In questo modo sarai in grado di verificarlo e assicurarti che tutto sia stato eseguito correttamente. Nota che non riceverai un'e-mail se non c'è output dal comando cron job.

Tieni presente che riceverai un'e-mail per ciascuno dei lavori cron eseguiti. Questo potrebbe inondare la tua casella di posta nel caso in cui i tuoi croni corrano troppo spesso