Cómo ejecutar un cron job a mano, ahora

Cron no tiene un comando para ejecutar un job ahora: tienes que ejecutar su comando tú mismo. El problema es que desde tu terminal se ejecuta con otro usuario, otro shell y otras variables que en cron, así que puede funcionarte a ti y fallar en cron. Estas son las formas de ejecutarlo ahora, de la más rápida a la más parecida a lo que hace cron.

1. Copia el comando y ejecútalo con el usuario del crontab

Busca la línea con crontab -l (o sudo crontab -l para el crontab de root, y cat /etc/crontab /etc/cron.d/* para el del sistema). El comando es todo lo que va después de los cinco campos del horario, y después del usuario en /etc/crontab y /etc/cron.d/.

Al copiarlo, vuelve a convertir cada \% en %: cron quita la barra antes de ejecutar el comando. Después ejecútalo con el usuario del crontab, con /bin/sh como lo hace cron:

sudo -u www-data -H sh -c '/ruta/a/job.sh'
echo $?

Para el crontab de root, sudo sh -c '...', y para el tuyo, sh -c '...'. echo $?, justo después, muestra el código de salida del comando: 0 significa que salió bien, y otro número suele indicar que falló (qué significa cada uno está en los códigos de salida de un cron job). Si el comando funciona así y falla en cron, la diferencia está en el entorno: pasa al punto 2.

2. Ejecútalo con el entorno de cron

Cron no lee el perfil del usuario: inicia el comando con pocas variables, un PATH corto y el directorio personal del usuario como directorio de trabajo. Para ejecutarlo casi como lo hace cron, con el mismo usuario del punto 1 (aquí www-data, cuyo directorio personal es /var/www; getent passwd www-data lo muestra):

sudo -u www-data env -i HOME=/var/www LOGNAME=www-data SHELL=/bin/sh PATH=/usr/bin:/bin \
  /bin/sh -c 'cd "$HOME" && /ruta/a/job.sh' < /dev/null
echo $?

Para tu propio crontab, quita sudo -u www-data y usa tus variables: HOME="$HOME" LOGNAME="$USER".

< /dev/null lo deja sin entrada, como en cron: un comando que pide algo, como una contraseña o la confirmación de la clave de un host SSH, falla aquí como fallaría en cron.

Cron puede definir otras variables, según el sistema y el crontab. Para ver en qué se diferencia su entorno del de tu terminal, agrega esta línea al mismo crontab, espera un minuto y quítala:

* * * * * env > /tmp/cron-env

Después, en tu terminal y con el mismo usuario, compara los dos:

diff <(sort /tmp/cron-env) <(env | sort)

Las líneas con < son las de cron, y las que tienen >, las de tu terminal: normalmente PATH, SHELL y las variables de tu perfil. Define las que el job necesita en el crontab o en el script (las causas más comunes están en por qué tu cron job no se ejecuta). Para reproducir la ejecución real, con todo el entorno de cron, deja que cron lo ejecute, en el punto 3.

3. Deja que cron lo ejecute en dos minutos

La prueba más segura es dejar que lo ejecute cron. Copia la línea con un horario un par de minutos más adelante: si son las 14:32, 34 14 * * *. Cron lee el cambio cuando guardas con crontab -e, ejecuta la línea a las 14:34 con su entorno real y su MAILTO, y puedes seguirla en los logs de cron. Después, quita la copia.

Los jobs de /etc/cron.daily y los otros directorios

Esos scripts se ejecutan con run-parts. Para ejecutar ahora todos los de un directorio, o solo un script:

sudo run-parts /etc/cron.daily
sudo /etc/cron.daily/logrotate; echo $?

En Debian y Ubuntu, run-parts se salta los archivos con un punto en el nombre, como respaldo.sh: si un script no se ejecuta solo, puede ser por eso.

Los timers de systemd

Un timer inicia un servicio, y ese servicio se puede iniciar ahora:

sudo systemctl start respaldo.service
systemctl status respaldo.service
journalctl -u respaldo.service -n 50

systemctl status muestra cómo terminó, con su código de salida en el status= del proceso, y journalctl muestra su salida. systemctl list-timers --all muestra los timers y sus servicios (más en cómo listar los cron jobs).

Kubernetes y Docker

Un CronJob de Kubernetes puede crear un job ahora, con la misma plantilla:

kubectl create job --from=cronjob/respaldo respaldo-manual
kubectl get job respaldo-manual
kubectl logs job/respaldo-manual

kubectl get job muestra si se completó, y kubectl logs muestra su salida.

En un contenedor de Docker, ejecuta el comando con docker exec, teniendo en cuenta que el cron del contenedor puede no ver las variables del contenedor (mira cómo ejecutar cron jobs en un contenedor de Docker). docker exec termina con el código de salida del comando:

docker exec mi-contenedor /ruta/a/job.sh; echo $?

Entérate cuando falle solo

Ejecutarlo a mano te dice si funciona ahora. Para saber cuándo falla a las 3 de la mañana, el job tiene que avisar de cada ejecución: cuándo empieza, cuándo termina y con qué código.