Captura de la salida de cron

Introducción

Las tareas de cron se ejecutan en segundo plano, sin estar vinculadas a ninguna sesión de terminal. Esto resulta ideal para la automatización, pero dificulta la depuración: si un script falla, no verá el mensaje de error en la pantalla.

Cuando una tarea de cron genera salida, el sistema tradicionalmente intenta enviarla por correo electrónico al usuario. En muchos servidores modernos, contenedores o entornos de formación, la entrega de correo no está configurada. Por eso, la salida puede desaparecer por completo si usted no la redirige.

Esta es una de las razones por las que a los principiantes suele resultarles difícil entender cron: la tarea puede ejecutarse exactamente según lo programado, pero los mensajes de error no aparecen en el terminal donde se creó el crontab. La automatización en segundo plano requiere un registro explícito.

En este laboratorio, aprenderá a capturar esta salida «silenciosa» para depurar fallos. Usted:

1. Simulará un fallo: creará una tarea de cron que generará un error de forma garantizada.
2. Redirigirá el error estándar: utilizará el operador 2> para capturar los mensajes de error.
3. Analizará los registros: leerá la salida capturada para verificar la causa del fallo.

Crear una tarea de cron que falle

Primero, cree deliberadamente una tarea incorrecta para simular un fallo. Indicará a cron que muestre el contenido de un directorio que no existe.

Abra el crontab de su usuario:

crontab -e

Vaya al final del archivo, después de cualquier comentario, y añada esta línea:

* * * * * ls /this/directory/does/not/exist

Detalles de la configuración:

• Programación: * * * * * (se ejecuta cada minuto).
• Comando: ls ... (intenta mostrar el contenido de una ruta que no existe).

Guarde los cambios y salga del editor.

Ahora, espere al menos un minuto.

Observe el terminal. ...

No aparece nada en la pantalla. Este es un fallo silencioso. El comando se ejecutó, falló y generó un mensaje de error, pero el mensaje no tenía ningún destino, por lo que se descartó.

Que no aparezca nada no significa que «no haya ocurrido nada». Significa que el proceso no tenía un terminal interactivo asociado. Entender esta diferencia es esencial para depurar tareas programadas.

Redirigir el error estándar (stderr)

Para ver el mensaje de error, debe redirigir el flujo de error estándar (stderr) a un archivo.

En Linux, los descriptores de archivo se numeran así:

• 0: entrada estándar (stdin)
• 1: salida estándar (stdout)
• 2: error estándar (stderr)

Utilice 2> para redirigir el canal 2, que corresponde a los errores, a un archivo.

Esto utiliza el mismo modelo de redirección del shell que aprendió anteriormente. Cron inicia un comando, el shell gestiona sus descriptores de archivo y la redirección determina dónde termina cada flujo.

Abra de nuevo el crontab:

crontab -e

Modifique la línea para que quede exactamente así:

* * * * * ls /this/directory/does/not/exist 2> /home/labex/project/cron_error.log

Cambios principales:

• 2>: redirige el flujo de error.
• /home/labex/project/cron_error.log: ruta absoluta del archivo de registro.
  • Importante: utilice siempre rutas absolutas, como /home/labex/..., en las tareas de cron. Cron se ejecuta en un entorno mínimo y no sabe a qué hacen referencia ~ ni las rutas relativas.

Ese entorno mínimo es otro concepto importante de cron. Normalmente, las tareas programadas disponen de menos variables de entorno, un PATH limitado y ningún contexto de shell interactivo. Por eso, los comandos que funcionan manualmente pueden fallar bajo cron si dependen de suposiciones implícitas.

Guarde los cambios y salga.

Analizar el archivo de registro

Espere otro minuto para que la tarea se ejecute de nuevo.

Ahora, compruebe si el archivo de registro ha capturado el error:

cat ~/project/cron_error.log

Debería ver el mensaje de error registrado claramente: ls: cannot access '/this/directory/does/not/exist': No such file or directory

Limpieza: no es una buena práctica dejar tareas que fallan ejecutándose en segundo plano.

1. Abra crontab -e.
2. Elimine la línea asociada a este laboratorio.
3. Guarde los cambios y salga.

Ahora ha depurado correctamente una tarea en segundo plano mediante la captura de su salida de error.

En las operaciones reales, muchos problemas de cron se deben al entorno, a rutas inexistentes o a permisos insuficientes, y no a una sintaxis incorrecta del comando. La salida capturada suele ser la forma más rápida de determinar qué tipo de problema tiene realmente.

Resumen

En este laboratorio, aprendió a gestionar la salida de tareas de cron ejecutadas en segundo plano:

1. El problema: las tareas de cron fallan silenciosamente si no se gestiona su salida.
2. La solución: utilizar la redirección del error estándar (2>) para capturar los mensajes de fallo.
3. Buena práctica: registrar siempre la salida de las tareas automatizadas para poder depurarlas cuando fallen.

Esta técnica (2> error.log) es esencial para mantener scripts de automatización fiables en cualquier entorno Linux.