Por dónde empezar a diagnosticar el cronjob simple

0

Tengo un servidor Ubuntu con un solo usuario y el siguiente crontab:

# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and crontab(8)
# 
# m h  dom mon dow   command
MAILTO=<my email>
* * * * * echo "Test"

Tan simple como es este trabajo cron, no recibo ningún correo electrónico. También he intentado modificarlo de la siguiente manera (en caso de que haya un problema con mi correo electrónico):

* * * * * echo "Test" >> test.txt

pero el archivo test.txt nunca se crea

Esto parece una De Verdad problema simple, pero normalmente cuando tengo problemas con los trabajos cron, en realidad se está ejecutando y el trabajo está generando un error. No sé cómo empezar a diagnosticarlo cuando el trabajo ni siquiera se está ejecutando.

Actualización con salida de service cron status

sbarnett@sbarnett:~$ service cron status
Failed to get properties: Access denied
sbarnett@sbarnett:~$ sudo service cron status
[sudo] password for sbarnett:
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2017-08-15 14:15:52 MST; 3 weeks 1 days ago
     Docs: man:cron(8)
 Main PID: 1682 (cron)
   CGroup: /system.slice/cron.service
           └─1682 /usr/sbin/cron -f

Sep 07 09:55:01 sbarnett.vm CRON[3144]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 09:55:01 sbarnett.vm CRON[3145]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Sep 07 10:05:01 sbarnett.vm CRON[3151]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 10:05:01 sbarnett.vm CRON[3152]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Sep 07 10:05:01 sbarnett.vm CRON[3151]: pam_unix(cron:session): session closed for user root
Sep 07 10:15:01 sbarnett.vm CRON[3156]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 10:15:01 sbarnett.vm CRON[3157]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Sep 07 10:17:01 sbarnett.vm CRON[3159]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 07 10:17:01 sbarnett.vm CRON[3160]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 07 10:17:01 sbarnett.vm CRON[3159]: pam_unix(cron:session): session closed for user root
stevendesu
fuente
No tengo conocimiento de cron (por lo que esto podría ser una mierda completa), pero tiene sentido para el comodín todos cinco campos? ¿Cuándo esperaría que el trabajo se ejecute con esta configuración, en cada momento dado, todos los días? Intentaría poner algo en el campo de los minutos al menos.
Aganju
Comprobar que el cron el servicio se está ejecutando: service cron status; si no entonces sudo service cron start.
AFH
@Aganju - Todos los campos configurados para * Es perfectamente válido: ejecuta una tarea cada minuto.
AFH
¿Está seguro de que tiene un agente de correo electrónico local en ejecución?
JakeGould
Amplificando el comentario de @ JakeGould, deberías verificar que mail se configura correctamente usándolo para enviar un correo electrónico de prueba: vea man mail para detalles.
AFH

Respuestas:

0

En Ubuntu, el crontab es un poco diferente, hay un campo de "usuario" después del selector de tiempo ...

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly

Para depurar puede intentar usar un comando simple como:

logger "This goes to /var/log/syslog"

Y compruebe que si va a ese archivo de registro en los tiempos esperados. Luego llama a un script en su lugar (un script que a su vez llama logger ...)

xenoid
fuente
Ese campo no está presente en Ubuntu 16.04.
AFH
El extracto de crontab anterior es de mi PC que ejecuta Kubuntu 16.04 y tengo el mismo en un servidor que ejecuta Ubuntu Server 16.04
xenoid
Este no es el problema que estoy teniendo ni resuelve mi problema. Estoy en Ubuntu 16.04 y no hay una columna de usuario. Sin embargo, gracias por intentarlo.
stevendesu
0

Mi problema en particular parecía ser extraño, cuyos detalles no entiendo del todo, pero a través de algunas conjeturas y la lectura de varios mensajes en el foro encontré la respuesta.

A veces las actualizaciones del sistema operativo pueden atascar los permisos en sus archivos cron. Cualquiera (o todo) de lo siguiente puede arreglarlo:

  • sudo service cron reload
  • sudo service cron restart
  • sudo /etc/init.d/cron restart
  • shutdown -r now
  • sudo apt-get dist-upgrade

Básicamente:

  • Intenta reiniciar el demonio cron
  • Intenta reiniciar tu computadora
  • Si todo lo demás falla, puede haber una actualización que solucione el problema.
stevendesu
fuente