Respuestas:
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 los archivos o enviárselas por correo. Dentro de crontabs funciona la redirección de shell estándar .
Por ejemplo, para redirigir la salida de error de some_job.sh
a some_job.err
y descartando la salida estándar (es decir, de enviarlo a /dev/null
) añadir el siguiente cambio de dirección a su crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
o enviárselo por correo (si mail
está disponible)
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 a /dev/null
y solo después de stderr a stdout (que ahora ya no contiene nada). De esa manera solo su stderr termina en stdout y se pasa a mail
.
La mayoría de los demonios cron en las plataformas con las que he trabajado envían por correo electrónico automáticamente el stdout / stderr de los trabajos cron del usuario al usuario de cuyo crontab vino el trabajo. Olvidé lo que sucede con todo el sistema (trabajos cron no específicos del usuario desde / etc / crontab). La cuestión es que la gente ya no siempre 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 tipo Unix. Por lo tanto, los correos electrónicos de salida del trabajo cron simplemente mueren en una carpeta de spool de correo local en algún lugar si incluso llegan tan lejos. Entonces, una respuesta podría ser encender su demonio de correo y quizás asegurarse de tener un archivo ~ / .forward para reenviar su correo local a 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 @honk sugirió, o, suponiendo que su trabajo cron sea un script de shell, puede tener su script call logger (1) o syslog (1) o cualquier otra herramienta de línea de comandos que su sistema operativo proporcione 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 en dónde, tal vez editando /etc/syslog.conf.
La mayoría de mis trabajos cron invocan scripts de bash que escribí específicamente con el propósito de ser iniciados por cron por una razón particular. En esos, especialmente cuando los escribo y depuro inicialmente, me gusta usar "set -vx" de bash para hacer que la forma no expandida y expandida de cada línea del script de shell se escriba en stdout antes de que se ejecute. Tenga en cuenta que los scripts de shell iniciados desde cron se consideran shells no interactivos y sin inicio de sesión, 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.
mail
comando para leer mensajes desde la línea de comando. O mira /var/spool/mail
. Pero si ha instalado postfix u otro programa de correo que no sea sendmail estándar, se necesita otra forma de leer los mensajes.
mail -s "cron output" test@example.com
funciona bien: /
less $MAIL
si desea ver la salida cron para el usuario actual o less /var/spool/mail/root
si desea ver la salida cron para los comandos que se ejecutan como root.
La forma más simple es capturar errores de impresión y guardarlos en un archivo. Tengo un cronjob que llama a una línea de comando php, como este:
1 0 * * * php /pathOfMyApp/index.php controllerName functionName> / pathOfMyApp / log / myErrorLog 2> & 1
La parte anterior a '>' es mi cronjob y después de '>' es la captura y el almacenamiento en un archivo ubicado en una carpeta de registro en la raíz de mi proyecto, pero podría estar en el lugar que desee. Esté alerta: cada vez que se llame a cronjob, sobrescribirá el último registro. Puede usar '>>' para escribir al final de un archivo existente o buscar el comando de terminal 'cat'.
Si su crontab usa 'curl' o 'wget' y hace referencia a un enlace, puede buscar en / var / log / httpd / appName el registro de acceso, si cron regresa con 500 o 400 debe estar mal.
Por último, también puede consultar / var / log / messages.
Creo que la redirección dentro del archivo cron podría no ser la mejor opción en este caso.
A menudo, desea que la especificación de registro se ubique junto con el script de trabajo cron. En este caso, sugiero lo siguiente:
#!/bin/bash
exec &>> capture-log.txt
echo "Running cron-job foo at $(date)"
...
<rest of script>
Esto agrega la salida del trabajo cron al archivo capture-log.txt.
Prefiero recibir informes por correo electrónico sobre trabajos cron. Sólo hay que poner
MAILTO=yourmail@domain.com
en crontab y recibirás un correo electrónico. Por supuesto, debe tener un correo electrónico configurado para su cuenta.