Risposte:
Controlla se i programmi che esegui con cron hanno i propri file di registro. Se non lo fanno, ma scrivono il loro output negli output standard, puoi reindirizzarli a file o inviarli via e-mail. All'interno di crontabs il reindirizzamento delle shell standard funziona.
Ad esempio, per reindirizzare l'output di errore di some_job.sh
per some_job.err
e scartando l'uscita standard (cioè di inviarlo al /dev/null
) aggiungere la seguente reindirizzamento al vostro crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
oppure per inviarlo via e-mail (se mail
disponibile)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" you@example.org
/dev/null
?
some_job.sh
stdout allo /dev/null
e solo dopo lo stderr allo stdout (che ora non contiene più nulla). In questo modo solo il suo stderr finisce in stdout e viene passato a mail
.
La maggior parte dei demoni cron su piattaforme con cui ho lavorato inviano automaticamente tramite e-mail lo stdout / stderr dei lavori cron dell'utente all'utente da cui proviene il crontab del lavoro. Dimentico cosa succede a livello di sistema (lavori cron non specifici dell'utente da / etc / crontab). Il fatto è che le persone non sempre impostano un demone mailer (ovvero un Mail Transfer Agent (MTA) come sendmail, qmail o postfix) sulla maggior parte dei sistemi operativi simili a Unix. Quindi le e-mail di output del lavoro cron semplicemente muoiono in una cartella di spool della posta locale da qualche parte se arrivano anche così lontano. Quindi una risposta potrebbe essere solo quella di accendere il tuo demone mailer e magari assicurarti di avere un file ~ / .forward per inoltrare la tua posta locale al tuo "vero" account di posta elettronica.
Se si desidera che i lavori vengano scritti in file di registro specifici, è possibile utilizzare il reindirizzamento di output standard come suggerito da @honk oppure, supponendo che il proprio lavoro cron sia uno script di shell, è possibile avere il proprio script call logger (1) o syslog (1) o qualsiasi altro strumento da riga di comando fornito dal sistema operativo per l'invio di messaggi arbitrari a syslog. Quindi potresti usare i metodi integrati del tuo SO per configurare quali tipi di messaggi vengono registrati dove, magari modificando /etc/syslog.conf.
La maggior parte dei miei lavori cron invocano script bash che ho scritto appositamente allo scopo di essere avviato da cron per un motivo particolare. In quelli, specialmente quando inizialmente li scrivo e debug, mi piace usare "set -vx" di bash per fare in modo che la forma espansa ed espansa di ogni riga dello script della shell venga scritta su stdout prima che venga eseguita. Si noti che gli script di shell avviati da cron sono considerati shell non di accesso e non interattivi, quindi gli script di avvio della shell standard come .bashrc e .profile non vengono eseguiti. Se usi bash e vuoi che bash esegua uno script di avvio, devi definire una variabile di ambiente "BASH_ENV = / path / to / my / startup / script" nel tuo crontab prima della riga in cui definisci il lavoro.
mail
comando per leggere i messaggi dalla riga di comando. O guarda /var/spool/mail
. Ma se hai installato postfix o altro mailer rispetto a sendmail standard, è necessario un altro modo per leggere i messaggi.
mail -s "cron output" test@example.com
funziona benissimo: /
less $MAIL
se vuoi vedere l'output cron per l'utente corrente o less /var/spool/mail/root
se vuoi vedere l'output cron per i comandi in esecuzione come root.
Il modo più semplice è acquisire errori di stampa e salvarli in un file. Ho un cronjob che chiama una riga di comando php, in questo modo:
1 0 * * * php /pathOfMyApp/index.php controllerName functionName> / pathOfMyApp / log / myErrorLog 2> & 1
La parte prima di '>' è il mio cronjob e dopo '>' è l'acquisizione e il salvataggio in un file situato in una cartella di registro nella radice del mio progetto, ma potrebbe essere nel posto desiderato. Fai attenzione: ogni volta che verrà chiamato cronjob, sovrascriverà l'ultimo registro. Puoi usare '>>' per scrivere alla fine di un file esistente o cercare il comando terminale 'cat'.
Se il tuo crontab usa 'curl' o 'wget' e fa riferimento a un link, puoi cercare in / var / log / httpd / appName per access-log, se cron ritorna con 500 o 400 deve essere qualcosa di sbagliato.
Alla fine, puoi anche controllare / var / log / messages.
Penso che il reindirizzamento all'interno del file cron potrebbe non essere l'opzione migliore in questo caso.
Spesso si desidera che la specifica di registrazione sia collocata nello script cron job. In questo caso, suggerisco quanto segue:
#!/bin/bash
exec &>> capture-log.txt
echo "Running cron-job foo at $(date)"
...
<rest of script>
Ciò accoda l'output dal processo cron al file capture-log.txt.
Preferisco ricevere rapporti e-mail sui lavori cron. Metti solo
MAILTO=yourmail@domain.com
in crontab e riceverai un'email. Ovviamente devi avere la posta elettronica configurata per il tuo account.