¿Por qué mi crontab no se activó?

Solía crontab -eagregar la siguiente línea a mi crontab:

* * * * * echo hi >> /home/myusername/test

Sin embargo, no veo que se escriba el archivo de prueba. ¿Es este un problema de permiso o crontab no funciona correctamente?

Veo que el proceso cron se está ejecutando. ¿Cómo puedo depurar esto?

Editar : Ask Ubuntu tiene una buena pregunta sobre crontab , desafortunadamente eso todavía no me ayuda.

Edición 2 - Hmm, parece que mi archivo de prueba tiene 214 líneas, lo que significa que durante los últimos 214 minutos se ha escrito en cada minuto. No estoy seguro de cuál era el problema, pero evidentemente se ha ido.

Hay implementaciones de cron(no todas, y no recuerdo cuál de manera improvisada, pero encontré una en Linux) que comprueban los archivos crontab actualizados cada minuto y no consideran nuevas entradas hasta el siguiente minuto. . Por lo tanto, un crontab puede tardar hasta dos minutos en iniciarse por primera vez. Esto puede ser lo que observaste.

¿Has agregado una línea vacía después de tu cronjob ?

Tuve el mismo problema: un crontab que funcionaba se detuvo repentinamente después de agregar una nueva entrada al final. Resultó que me había olvidado de poner una nueva línea después de esa última línea.

Lo descubrí emitiendo el comando

cat /var/log/syslog | grep crontab

y la salida mostró el problema:

Jul  2 08:16:01 shiva cron[1254]: (*system*) RELOAD (/etc/crontab)
Jul  2 08:16:01 shiva cron[1254]: (*system*) ERROR (Missing newline before EOF, this crontab file will be ignored)

Agregar la nueva línea y guardar solucionó el problema.

Parece que esto está arreglado. La próxima vez, intente registrar el STDERR también. Lo siguiente solo se registrará en STDOUT, no en STDERR:

* * * * * echo hi >> /home/myusername/test

Intente asegurarse de que también hay una cláusula explícita para STDERR. De lo contrario, STDERR puede enviarse por correo electrónico al usuario (suponiendo que el correo electrónico esté funcionando) o puede no ir a ningún lado, dependiendo de cómo esté configurado Cron.

* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr

Mi preferencia es enviar la salida de cronjob a syslog. De esta forma, estoy aprovechando cualquier infraestructura de syslog existente (syslogs centralizados, Splunk, rotación de registros ya admitida, es fácil comparar mensajes en / var / log / messages & / var / log / cronjob, etc.), y no estoy enviando spam a los administradores de sistemas (yo) con correos electrónicos innecesarios.

* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob

Conmigo el problema era que el script no era ejecutable. Tenía crontab -e configuración como esta

* * * * * /bin/my-script.sh

Y el archivo myscript no era ejecutable, así que ejecuté

chmod +x my-script.sh

Inmediatamente comencé a ver la salida como se esperaba.

Su línea cron funciona bien en mi computadora cuando cambio myusernaea phunehehe. Hay varias formas de averiguar qué le sucede a su sistema.

Cron generalmente envía un correo al usuario cuando hay algo mal. Si ve el mensaje "Tiene correo", use un cliente de correo para revisar su bandeja de entrada . O, consulte en su directorio de inicio, puede haber un archivo llamado dead.letterallí.

Puede verificar las /var/log/entradas relacionadas con cron. En mi computadora, el archivo de registro está en /var/log/cron/current(requiere acceso de root).

Si tiene acceso de root, puede detener el demonio cron e iniciarlo en modo de depuración. Por ejemplo, usaría (cambiar fcronel nombre de tu demonio):

killall fcron
fcron --foreground --debug

Lo más probable es que, cuando cron falla, genera un correo electrónico para la identificación del usuario del trabajo cron en esa computadora. Si no tiene un MTA trabajando en su computadora, o no está leyendo o reenviando ese correo a otro lugar, no verá ese mensaje, incluso si el MTA está funcionando.

Una buena manera de obtener los errores de su crontab por correo es hacer que su crontab se vea así:

MAILTO="myemail@example.com"
* * * * * echo hi >> /home/myusernae/test

Obviamente, use su dirección de correo electrónico en lugar de myemail@example.com. Esto le dice a cron que envíe errores a su dirección de correo electrónico en lugar de a la cuenta local. En particular, esto es útil si tiene un crontab raíz (o un fragmento de crontab en /etc/cron.d) al que desea enviarle la salida, puede evitar el spam del buzón de la raíz o la dirección de reenvío de la raíz.

Supongo que una razón para esto puede ser que el directorio / home / está encriptado y cuando el usuario está desconectado, cron no puede hacer nada en ese directorio.

ver: https://stackoverflow.com/a/40354269/1279002