Compruebe si los programas que ejecuta con cron tienen sus propios archivos de registro. Si no lo hacen, pero escriben su salida en las salidas estándar, puede redirigirlas a archivos o enviárselas por correo. Dentro de crontabs funciona la redirección de shell estándar.
P.ej. para redirigir la salida de error de some_job.sh a some_job.err y descartando la salida estándar (es decir, enviándola a /dev/null ) agregue la siguiente redirección a su crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
o para enviárselo por correo (si mail está disponible)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" [email protected]
La mayoría de los demonios cron en las plataformas con las que he trabajado envían automáticamente por correo electrónico el stdout/stderr de los trabajos cron del usuario al usuario de cuyo crontab proviene el trabajo. Olvidé lo que sucede con todo el sistema (trabajos cron no específicos del usuario de /etc/crontab). La cuestión es que la gente ya no configura un demonio de correo (es decir, un agente de transferencia de correo (MTA) como sendmail, qmail o postfix) en la mayoría de los sistemas operativos similares a Unix. Entonces, los correos electrónicos de salida del trabajo cron simplemente mueren en una carpeta de cola de correo local en algún lugar si incluso reciben eso lejos. Entonces, una respuesta podría ser simplemente activar su demonio de correo, y tal vez asegurarse de tener un archivo ~/.forward para reenviar su correo local junto con su cuenta de correo electrónico "real".
Si desea que sus trabajos escriban en archivos de registro específicos, puede usar la redirección de salida estándar como sugirió @honk o, suponiendo que su trabajo cron es un script de shell, podría hacer que su script llame a logger(1) o syslog(1) o cualquier otra herramienta de línea de comandos que proporcione su sistema operativo para enviar mensajes arbitrarios a syslog. Luego, podría usar los métodos integrados de su sistema operativo para configurar qué tipos de mensajes se registran y dónde, tal vez editando /etc/syslog.conf.
La mayoría de mis trabajos cron invocan scripts bash que escribí específicamente con el propósito de que cron los inicie por una razón particular. En esos, especialmente cuando los escribo y los depuro inicialmente, me gusta usar "set -vx" de bash para hacer que la forma expandida y no expandida de cada línea del script de shell se escriba en la salida estándar antes de que se ejecute. Tenga en cuenta que los scripts de shell iniciados desde cron se consideran shells que no requieren inicio de sesión ni interactivos, por lo que sus scripts de inicio de shell estándar como .bashrc y .profile no se ejecutan. Si usa bash y desea que bash ejecute un script de inicio, debe definir una variable de entorno "BASH_ENV=/path/to/my/startup/script" en su crontab antes de la línea donde define el trabajo.
Las tareas que ejecuta cron son responsables de su propio registro.