Códigos de salida de un cron job: qué significan 1, 2, 126, 127 y 137

Todo comando termina con un número, su código de salida. Por convención, 0 indica que salió bien; los demás valores suelen indicar un error, pero qué significa cada uno depende del programa. Cron no lo muestra en ninguna parte por defecto, pero es la pista más rápida de por qué falló un job: algunos códigos apuntan directo a la causa.

Cómo ver el código de salida

• En tu terminal, justo después de ejecutar el comando: echo $?. Para ejecutarlo como lo haría cron, mira cómo ejecutar un cron job a mano.

• En el crontab, escríbelo en un log después del comando:

  0 3 * * * /ruta/a/job.sh >> /var/log/job.log 2>&1; echo "salida $?" >> /var/log/job.log

• En el log de cron, en Debian y Ubuntu, cron también puede registrar los jobs que terminan con error. Agrega -L 5 a EXTRA_OPTS en /etc/default/cron (1 registra el inicio de cada job, como por defecto, y 4 los que fallan) y reinicia cron. Dónde está ese log depende del sistema: mira dónde están los logs de cron.

Qué significa cada código

• 0: salió bien. Si aun así el job no hizo lo que debía, el script terminó sin darse cuenta del error (más sobre eso abajo).
• 1: un error general. El programa decide qué significa: lee su salida. Muchos programas, como grep cuando no encuentra nada, también lo usan para un resultado que no es un error.
• 2: mal uso o un archivo que falta. Un error de sintaxis del shell, una opción que el programa no conoce o, para ls y otros comandos, un archivo que no existe.
• 124: timeout lo detuvo. El comando estaba dentro de timeout y tardó más de lo permitido.
• 126: el comando existe, pero no se pudo ejecutar. Revisa:
  • que el script sea ejecutable: chmod +x /ruta/a/job.sh;
  • que la ruta sea un archivo, no un directorio;
  • que su sistema de archivos no esté montado con noexec (findmnt -T /ruta/a/job.sh muestra sus opciones).
• 127: no se encontró el comando. El más común en cron. Revisa, en este orden:
  • el PATH. El de cron suele ser solo /usr/bin:/bin, así que un comando en /usr/local/bin, o instalado con nvm o pyenv, no se encuentra. Usa la ruta absoluta, como /usr/local/bin/node, o define PATH en el crontab.
  • la primera línea del script, como #!/bin/bash: el intérprete que indica tiene que existir.
  • los fines de línea. Un script guardado en Windows falla con /bin/bash^M: bad interpreter. Corrígelo con sed -i 's/\r$//' /ruta/a/job.sh.
• 128 más un número: una señal lo terminó. El número es la señal:
  • 137 (128 + 9, SIGKILL): algo lo mató sin dejarlo terminar. Muchas veces es el OOM killer del kernel cuando se acaba la memoria (busca Out of memory en dmesg o journalctl -k), el límite de memoria de un contenedor o un kill -9.
  • 143 (128 + 15, SIGTERM): algo le pidió que se detuviera: el apagado del servidor, un reinicio del servicio o del contenedor, o un kill.
  • 130 (128 + 2, SIGINT): Ctrl+C. No pasa en cron, pero sí cuando ejecutas el job a mano.
• 255: depende del programa. ssh, por ejemplo, lo devuelve cuando no puede conectarse, y un programa que sale con -1 termina con 255.

El código va de 0 a 255: un script que termina con exit 256 termina con 0.

Cuando el código dice 0 pero el job falló

• Una tubería se queda con el código de su último comando. En /ruta/a/job.sh | tee job.log, el código es el de tee, que casi siempre termina bien. En bash, set -o pipefail conserva el error de cualquier comando de la tubería.
• Un script se queda con el código de su último comando, salvo que se detenga en el primer error. En bash, empieza con set -e, o comprueba cada paso.
• Una lista se queda con el código de su último comando. En job.sh; limpieza.sh, el código es el de limpieza.sh. Con job.sh && limpieza.sh, la limpieza solo se ejecuta si el job salió bien, y el código es el del que falló.

Recibe el código con cada ejecución

El código de salida te dice por qué falló un job solo si alguien lo ve. Un monitor que lo recibe con cada ejecución te avisa cuando no es 0, con el código en la alerta, y guarda el historial de los códigos de cada ejecución.