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 su file o inviarteli per posta. All'interno dei crontab il reindirizzamento della shell standard funziona.
Per esempio. per reindirizzare l'output dell'errore di some_job.sh a some_job.err e scartando lo standard output (ovvero inviandolo a /dev/null ) aggiungi il seguente reindirizzamento al tuo crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
o per inviartelo invece (se mail è disponibile)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" [email protected]
La maggior parte dei demoni cron sulle piattaforme con cui ho lavorato inviano automaticamente via email lo stdout/stderr dei lavori cron dell'utente all'utente da cui proviene il lavoro dal crontab. 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 di posta (ovvero un agente di trasferimento di posta (MTA) come sendmail, qmail o postfix) sulla maggior parte dei sistemi operativi simili a Unix. Quindi le e-mail di output del processo cron muoiono in una cartella di spool di posta locale da qualche parte se anche quella viene ricevuta lontano. Quindi una risposta potrebbe essere semplicemente quella di avviare il tuo demone di posta e magari assicurarti di avere un file ~/.forward per inoltrare la tua posta locale al tuo account di posta "reale".
Se vuoi che i tuoi lavori scrivano su file di registro specifici, puoi utilizzare il reindirizzamento dell'output standard come suggerito da @honk o, supponendo che il tuo lavoro cron sia uno script di shell, potresti avere il tuo script che chiama logger (1) o syslog (1) o qualunque altro strumento da riga di comando fornito dal sistema operativo per l'invio di messaggi arbitrari a syslog. Quindi potresti utilizzare i metodi integrati del tuo sistema operativo per configurare quali tipi di messaggi vengono registrati e dove, magari modificando /etc/syslog.conf.
La maggior parte dei miei lavori cron invoca 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 li eseguo, mi piace usare "set -vx" di bash per fare in modo che la forma non 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 interattive, 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 d'ambiente "BASH_ENV=/path/to/my/startup/script" nel tuo crontab prima della riga in cui definisci il lavoro.
Le attività che cron sta eseguendo sono responsabili della propria registrazione.