Cron vs timers de systemd: cron ejecuta líneas, los timers ejecutan unidades

LOS DOS RELOJES

El mismo job — respaldo nocturno a las 03:30 — en ambos relojes, y lo que cada uno deja atrás:

30 3 * * * /usr/local/bin/backup.sh

# foo.timer
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
# foo.service — the job itself

el veredicto del horario: los cinco campos de cron son el incumbent compacto; OnCalendar es más largo pero estrictamente más expresivo — Mon..Fri 09..17:00:00 es una línea, y RandomizedDelaySec evita mil máquinas machacando un solo servidor

estos relojes re-estampan desde los propios comandos del expediente — no pueden leer el journal de tu máquina; dónde está realmente tu journal: secciones 04 y 05.

LAS DISTANCIAS PRÁCTICAS

• Logging : los timers loguean stdout/stderr al journal por unidad; cron, en el mejor caso, manda correo al usuario local.
• Ejecuciones perdidas : un timer con Persistent=true se corre una vez al boot si le saltó su horario; cron simplemente salta.
• Dependencias : los timers saben esperar network-online.target o puntos de montaje; cron te obliga a escribir a mano la lógica de reintento dentro del script.
• Sintaxis : cron es una línea; un timer son dos ficheros. Ese es el coste entero del cambio.
• Opción monotónica: OnBootSec=15min — cambios del reloj de pared no pueden confundirlo.

04PROBAR UN TIMER SIN ESPERAR

Tres comandos responden todo — lista qué está planificado y cuándo disparará la próxima vez, corre el job a mano tal como lo haría el timer, y después lee sus logs:

systemctl list-timers --all                 # every timer, next + last run
sudo systemctl start backup.service         # fire the job now, same unit as the timer
journalctl -u backup.service -f             # watch its output live

Fíjate en el reparto: systemctl start backup.timer arma el horario; el service es el job. Si list-timers muestra tu timer, systemctl status backup.service está en verde, y el journal muestra tu output, toda la cadena funciona.

verify: systemctl list-timers --all → tu timer, última y próxima ejecución listadas

05CORRER UN JOB CRON A MANO

Los jobs cron corren con un entorno despojado, por eso «funciona en mi shell, falla en cron» es un género de bug. Para reproducir cron fielmente, corre el comando a través de sh con el entorno que usaría cron:

crontab -l                                  # confirm the exact line
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # did cron even fire it? (Debian/Ubuntu)
journalctl -u cron -n 20                    # same, on systemd distros

Esa env -i es la prueba manual honesta: un entorno desnudo con el PATH por defecto de cron. Los dos clásicos de cron — un PATH desnudo y un % sin comillas (cron lo trata como un salto de línea) — aparecen de inmediato en esa prueba.

verify: journalctl -u cron -n 20 → la entrada CRON de tu comando

«MI TIMER NO SE DISPARA»

Un timer que parece muerto suele tener su service fallando al instante. Cuatro causas, en el orden para comprobarlas:

1. Los nombres del service y del timer no coinciden. foo.timer dispara foo.service — una errata o una unidad renombrada y el timer «corre» al vacío. systemctl cat foo.timer muestra exactamente a quién apunta.
2. Editado pero sin recargar. Después de cambiar un fichero de unidad: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Sin esto tu nuevo horario no está vivo.
3. Comando de estado equivocado. systemctl status foo.timer siempre muestra active incluso estando ocioso — mira mejor list-timers en su lugar.
4. El service que dispara está fallando al instante. journalctl -u foo.service --since -1h muestra el crash que list-timers esconde.

verify: journalctl -u foo.service --since -1h → el crash que list-timers esconde

LA TABLA DE DECISIÓN

Reglas del pulgar : llevar un job a tu propia máquina systemd → timer. Recordatorio personal rápido o una caja que no montaste → cron. Cualquier cosa con dependencias, reintentos, o la necesidad de saber si de verdad corrió → timer, siempre. El patrón clásico — un rsync nocturno de respaldo bajo un timer con Persistent=true — garantiza que el respaldo ocurre incluso si la máquina dormía en el minuto pautado, cosa que cron simplemente no puede ofrecer.

fin de los dos relojes · nada se descargó · todo es local