Cron y automatización

Introducción

cron ejecuta órdenes en momentos definidos. Esta sesión lo utiliza para automatizar un script que ya funciona manualmente. No se empleará para coordinar procesos complejos: Airflow asumirá dependencias, reintentos e historial en M02. Todas las rutas de práctica pertenecen al volumen /bda-m00 preparado en la página 01.

Objetivos

Interpretar los cinco campos de una entrada crontab.
Usar rutas absolutas y logs en tareas programadas.
Evitar solapamientos con flock.
Diagnosticar una tarea que no se ejecuta como se esperaba.

No repetiremos las explicaciones de redirecciones, funciones de log o códigos de salida: se aplican aquí a la ejecución programada. cron es el proceso planificador; crontab es la herramienta con la que gestionas la tabla de tareas de un usuario.

1. Leer una expresión cron

minuto hora día-del-mes mes día-de-la-semana orden

Expresión	Lectura
`0 * * * *`	En el minuto 0 de cada hora.
`15 8 * * 1-5`	A las 08:15, de lunes a viernes.
`0 0 1 * *`	A medianoche, el día 1 de cada mes.
`/5 * * *`	Cada cinco minutos.

Para una prueba breve puede usarse * * * * *, pero hay que eliminarla o modificarla después: ejecutaría la tarea cada minuto.

Los minutos admiten 0–59, las horas 0–23, el día del mes 1–31, el mes 1–12 y el día de la semana 0–7 (domingo es 0 o 7, lunes 1). * selecciona todos los valores del campo, 1-5 un rango y */5 saltos de cinco dentro de ese campo. La hora se interpreta según la zona del contenedor; que el script escriba UTC no cambia la zona del planificador. Consulta date y date -u para compararlas.

Listas, rangos y límites de la sintaxis

Una coma permite enumerar valores. 30 8,18 * * * ejecuta a las 08:30 y a las 18:30; 15 14 * * 1,3,5, a las 14:15 los lunes, miércoles y viernes. Un paso se aplica dentro de su campo: */35 en minutos significa minutos 0 y 35 de cada hora, no un intervalo continuo de 35 minutos entre ejecuciones.

En cron de Debian, cuando se restringen tanto día del mes como día de la semana, basta con que coincida uno de esos campos. 0 3 1-7 * 1 no significa «primer lunes»: también coincide con los días 1–7 y con los demás lunes. No traslades sin comprobar los ejemplos del tutorial anterior.

Las marcas L, W, # y ? aparecen en otros planificadores, pero no las utilizaremos en el cron de este laboratorio. Existen abreviaturas como @daily y @hourly; mantenemos los cinco campos en las prácticas para hacer visible su interpretación. @reboot se refiere al arranque del demonio cron, no necesariamente al encendido del equipo anfitrión.

La tabla editada con crontab -e tiene cinco campos y la orden. /etc/crontab y los archivos de /etc/cron.d añaden un campo de usuario. No copies ese usuario en la tabla personal: se interpretaría como parte de la orden. Aquí solo editamos la tabla del usuario actual mediante crontab, no archivos internos del planificador.

2. Cron no es tu terminal

Cron no carga necesariamente .bashrc y trabaja con un entorno reducido. Por eso hay que usar rutas absolutas, declarar el PATH mínimo y redirigir la salida a un log. No programes un script que no hayas ejecutado y verificado antes de forma manual.

La línea de la tarea la interpreta la shell de cron (habitualmente /bin/sh); cuando ejecuta un archivo con permisos, su shebang selecciona Bash. No presupongas que el directorio de trabajo es el volumen: usa rutas absolutas o dedúcelas de la ubicación del script.

No soluciones un fallo cargando indiscriminadamente .bashrc o copiando todas tus variables: documenta las dependencias concretas. El porcentaje % tiene un significado especial en la línea de una tarea y debe escaparse si se necesita allí literalmente. Nuestros formatos de date contienen % dentro del script, por lo que no necesitan ese escape de cron.

Comprobar e iniciar el servicio cron

Guardar una tarea con crontab -e no inicia el proceso que la ejecutará. En este laboratorio Docker, el contenedor arranca con Bash y cron no se inicia automáticamente. Gestiona el servicio dentro de Debian, como root, no en el anfitrión.

Primero consulta su estado:

service cron status

Si indica que está funcionando, no tienes que arrancarlo otra vez. Si está detenido, inícialo y vuelve a comprobar:

service cron start
service cron status

El texto exacto puede variar; busca que indique que está en ejecución, por ejemplo cron is running. Consultar el estado de un servicio detenido puede devolver un código no cero: ese resultado sirve para diagnosticarlo, no significa necesariamente que la orden esté mal escrita.

service permite utilizar el script de gestión del servicio. Estas son las operaciones principales; no las ejecutes todas seguidas:

Orden	Para qué sirve
`service cron status`	Consultar si el servicio está funcionando.
`service cron start`	Iniciarlo si está detenido.
`service cron stop`	Detenerlo; mientras esté detenido no lanzará nuevas tareas.
`service cron restart`	Detener y volver a iniciar el servicio. No hace falta para guardar tareas.

Ejecutar directamente cron también inicia el programa, pero usaremos service cron start para gestionar su arranque de forma más clara. Si al repetir cron aparece can't lock /var/run/crond.pid y se menciona otro proceso, normalmente ya hay una instancia funcionando: consulta el estado. No borres el archivo PID ni lances más instancias para intentar resolverlo.

Después de detener y volver a iniciar el contenedor, comprueba el estado y utiliza service cron start si está detenido. Abrir otra terminal no exige reiniciarlo. Editar y guardar crontab tampoco requiere reiniciar el servicio: cron detecta los cambios. La próxima ejecución llegará cuando coincida el horario, no inmediatamente al guardar.

No utilizamos systemctl en este contenedor: no se ha preparado para ejecutar systemd como proceso de inicio. Gestionar cron mediante service tampoco añade un arranque automático al contenedor. Referencia: service en Debian Trixie.

La tabla pertenece al usuario actual del contenedor (root), no al usuario del equipo anfitrión. El contenedor y Docker deben seguir en ejecución para que se realicen las tareas; cron no recupera por sí solo las ejecuciones perdidas mientras estaban detenidos. Los archivos del volumen persisten, pero paquetes y crontab pertenecen al contenedor y deben prepararse de nuevo si lo eliminas.

Usaremos scripts/fecha-utc.sh, preparado en la página 03. Compruébalo manualmente antes de programarlo:

/bda-m00/scripts/fecha-utc.sh
echo "$?"

Debe producir una fecha UTC y código 0. Edita tu tabla de tareas:

crontab -e

Si todavía no existe una tabla, crontab -l puede devolver «no crontab for root» con código no cero: es un estado inicial posible, no prueba de que falte el programa. Después de guardar con crontab -e, vuelve a listar para verificar la entrada. Cada línea debe terminar con salto de línea.

Si se solicita un editor, elige nano. Añade las siguientes líneas sin borrar otras tareas. PATH define los directorios de búsqueda; las rutas del script y del archivo de registro son absolutas porque cron no parte de /bda-m00.

# crontab
PATH=/usr/local/bin:/usr/bin:/bin
*/5 * * * * /bda-m00/scripts/fecha-utc.sh >> /bda-m00/logs/cron.log 2>&1

3. Evitar solapamientos

Si una ejecución tarda más que el intervalo programado, puede empezar otra antes de que termine la primera. flock -n intenta obtener un bloqueo exclusivo y devuelve de inmediato código 1 si ya está ocupado. El archivo identifica el bloqueo; su existencia no significa que esté bloqueado. El bloqueo lo mantiene el proceso y se libera cuando termina.

Sustituye solo la línea de la tarea anterior por esta variante, conservando PATH:

# crontab
*/5 * * * * /usr/bin/flock -n /bda-m00/.fecha.lock /bda-m00/scripts/fecha-utc.sh >> /bda-m00/logs/cron.log 2>&1

Todas las ejecuciones que quieras coordinar, incluidas las manuales, deben usar el mismo archivo de bloqueo. Un proceso que ejecuta el script directamente no queda protegido por esta entrada cron. El conflicto con -n puede no producir ningún mensaje: un log vacío no demuestra por sí solo que la tarea no se haya lanzado.

Para comprobar el bloqueo, usa dos terminales de Debian. Desde el anfitrión puedes abrir la segunda con docker exec -it bda-m00-debian bash. En la primera, sleep 15 mantiene una espera de quince segundos mientras flock conserva el bloqueo:

flock -n /bda-m00/.prueba.lock sleep 15

Antes de que termine, ejecuta en la segunda:

flock -n /bda-m00/.prueba.lock /bda-m00/scripts/fecha-utc.sh
echo "$?"

Debe devolver 1 sin ejecutar el script. Repite después de terminar la espera: debe mostrar una fecha y devolver 0. No borres el archivo de bloqueo para intentar desbloquearlo.

4. Comprobar y diagnosticar

crontab -l
tail -n 20 /bda-m00/logs/cron.log
command -v flock

El registro debe ganar una línea en cada ejecución aceptada. Para comprobarlo durante la práctica, puedes cambiar temporalmente la frecuencia a cada minuto, esperar el siguiente cambio de minuto y leer el registro; después restaura la frecuencia o elimina solo esa línea con crontab -e. Si algo falla, sigue este orden:

Ejecuta el script manualmente con los mismos argumentos.
Comprueba con crontab -l que la entrada es la esperada.
Revisa las rutas absolutas y el permiso de ejecución.
Lee el primer error de cron.log.
Comprueba la disponibilidad de flock, si el bloqueo está ocupado y si el contenedor sigue activo. Consulta service cron status y, solo si está detenido, utiliza service cron start; no inicies otra instancia si ya está funcionando.

Seguir un registro mientras crece

tail -n 20 muestra una fotografía de las últimas líneas y termina. tail -f mantiene la consulta abierta y muestra las líneas nuevas conforme se añaden. Para distinguirlo de una tarea que se ha quedado bloqueada, prueba primero sin depender de cron.

Desde /bda-m00, prepara un registro de prueba y síguelo:

echo 'Inicio de la prueba' > logs/seguimiento.log
tail -f logs/seguimiento.log

Debe aparecer la primera línea y no volver todavía el prompt. Abre una segunda terminal del contenedor, como aprendiste en la página 01, y ejecuta:

cd /bda-m00
echo 'Segunda linea de prueba' >> logs/seguimiento.log

La nueva línea debe aparecer en la primera terminal, normalmente tras una breve espera. Allí pulsa Ctrl + C para detener solo el seguimiento y recuperar el prompt. Comprueba con cat logs/seguimiento.log que permanecen las dos líneas: detener tail no elimina el archivo.

Ahora puedes usar tail -f /bda-m00/logs/cron.log una vez que el registro exista para observar la tarea programada. Si no llega una línea, el seguimiento por sí solo no explica la causa: aplica las comprobaciones anteriores. tail -f no es un sistema de alertas ni una herramienta que coordine trabajos.

Ejercicios de refuerzo

Traduce a lenguaje natural tres expresiones cron distintas.
Programa temporalmente un script que añada fecha y hora a un log cada cinco minutos.
Explica qué ocurriría sin flock si una tarea programada tarda más que su intervalo.
Escribe la expresión cron que ejecutaría un script a las 07:30 de lunes a viernes y tradúcela a lenguaje natural.
Escribe la expresión cron que ejecutaría un script el primer día de cada mes a las 00:15 y comprueba que los cinco campos están en el orden correcto.
Ejecuta manualmente scripts/fecha-utc.sh y verifica su código de salida antes de programarlo con cron.
Convierte la ejecución relativa de scripts/fecha-utc.sh en una orden con rutas absolutas apropiada para cron.
Añade redirección de salida normal y de error a una entrada cron de prueba; indica qué archivo consultarías si la tarea falla.
Comprueba con crontab -l que una entrada guardada coincide exactamente con la que esperabas programar.
Simula un diagnóstico: la tarea no añade una fecha al registro. Escribe, en orden, las cinco comprobaciones que realizarías antes de modificar la configuración.

Ejercicios cron recuperados

ID	Actividad
CR-1	Describe las ejecuciones de `30 8,18 * * ` y `15 14 * 1,3,5`, identificando cada campo.
CR-2	Explica por qué `/35 * * *` no equivale a esperar siempre 35 minutos. Enumera las ejecuciones previstas entre las 10:00 y las 11:59.
CR-3	Analiza `0 3 1-7 * 1` según cron de Debian y explica por qué no expresa únicamente el primer lunes del mes. No la actives.
CR-4	Prepara un script no interactivo que registre fecha UTC, usuario y directorio actual. Pruébalo manualmente desde dos ubicaciones y, después, mediante una tarea temporal del contenedor con ruta absoluta y log. Retira solo su entrada al acabar y explica qué diferencias observas.

El informe del curso anterior que inspeccionaba Hadoop/YARN se adapta aquí al entorno mínimo: no se presupone que esos servicios existan. No se automatizan cambios de usuarios, borrados ni actualizaciones del sistema en estas actividades.

Relación con resultados de aprendizaje y criterios de evaluación

RA / CE	Evidencia
RA0.b)	Tarea cron con ruta absoluta, log y bloqueo; diagnóstico documentado.