Registrazione di TUTTI gli output stderr di crontab su file

12

Ad esempio, posso registrare stderruno script in questo modo:

* * * * * run_script.sh > /var/log.txt 2>&1

Ma voglio registrare stderrtutti gli script nel mio crontab. Posso aggiungere > /var/log.txt 2>&1tutti gli script, ma non va bene se ho centinaia di script cron. C'è un altro modo più semplice per farlo?

logs io-redirection cron

— Maslov Anton
fonte

6

In crontab, puoi impostare MAILTO in modo che punti a un alias di posta che esegue uno script. Lo script accetterebbe un messaggio di posta, toglierebbe le intestazioni e altri goop e registrerebbe il resto con il logger. Poiché tutto l'output dello script cron viene inviato all'indirizzo specificato da MAILTO, acquisiresti tutto.

Esempio: in crontab

MAILTO=myalias

In / etc / mail / alias (supponendo che tu stia usando sendmail)

myalias:"|/usr/local/bin/my-processing-script.sh"

e togliere lo script dalle intestazioni della posta ed elaborare l'output cron.

— Kyle Jones
fonte

puoi essere più specifico sulla configurazione di MAILTO, alias, MTA, script, ecc?

— endolito il

1

@endolith Ho modificato la risposta per fornire una configurazione di base che dovrebbe funzionare con Mmails sendmail e ampiamente compatibili. Dovrai scrivere tu stesso la sceneggiatura.

— Kyle Jones,

5

Qualsiasi output prodotto da un comando viene inviato all'utente specificato nella variabile d'ambiente MAILTO come impostato nel file crontab (5) o, se nessuna variabile MAILTO è impostata (o se si tratta di un lavoro at (1) o batch (1) ), al proprietario del lavoro. Se un comando non produce alcun output o se la variabile d'ambiente MAILTO è impostata su una stringa vuota, non verrà inviata alcuna posta.

Dal momento che utilizza la posta locale, in realtà non è necessario impostare nulla o forse installare mailx se non è già qui. Cron ti invierà l'output, puoi salvare la posta in un file e fare molte cose da lì. Cercare di modificare il modo in cui cron funziona per soddisfare le tue esigenze non è la strada da percorrere. Se non la pensi così, basta patch e ri-costruire cron, chiamalo my_cron e usalo al posto di cron. Ed essere pronti a mantenere eventualmente aggiornato my_cron e ricostruirlo spesso.

Aggiungi questo all'inizio di tutti i tuoi script per registrare tutto e fermarti al primo errore

exec 2>&1 > /var/log/YOUR_LOG_FILE
set -e

— aki
fonte

l'ordine di reindirizzamento dovrebbe essere l'opposto? > /var/log/YOUR_LOG_FILE 2>&1cioè, prima reindirizzare stdout su un file e solo successivamente reindirizzare stderr su stdout (che ora punta al file).

— jfs,

È piuttosto folle che su un server minimale sia necessario installare un servizio di posta, e possibilmente un client di posta, solo per leggere gli errori prodotti da Cron. Sembra una decisione di progettazione anarchica.

— James McMahon

0

La sceneggiatura di Ryan Ye su /programming//a/7145618/20774 è utile anche per questo, sebbene faccia sia stdout che stderr.

Ho un piccolo script cronlog.sh per farlo. Il codice dello script

#!/bin/sh
echo "[`date`] Start executing $1"
$@ 2>&1 | sed -e "s/\(.*\)/[`date`] \1/"
echo "[`date`] End executing $1"

Allora potresti fare

cronlog.sh /opt/scripts/sql_fetch >> your_log_file

Risultato di esempio

cronlog.sh echo 'hello world!'

[Mon Aug 22 04:46:03 CDT 2011] Start executing echo
[Mon Aug 22 04:46:03 CDT 2011] helloworld!
[Mon Aug 22 04:46:03 CDT 2011] End executing echo

— James McMahon
fonte