¿Cron o un timer de systemd?

Los dos ejecutan algo según un horario. La diferencia aparece cuando una tarea falla, cuando se alarga o cuando la máquina estaba apagada justo a la hora prevista.

Cron y sus dos trampas

crontab -e
# m h dom mon dow  command
15 3 * * *  /usr/bin/php /var/www/site/cron.php >> /var/log/site-cron.log 2>&1

• El entorno está casi vacío. PATH es mínimo y tu perfil de shell no se lee, así que una orden que funciona cuando la escribes falla aquí. Usa rutas absolutas.
• La salida es correo, no un registro. Sin la redirección de arriba va a un buzón local que nadie lee, y la tarea parece haberse ejecutado en silencio.

Si una tarea de cron parece no ejecutarse nunca, la lista de Tareas de cron que nunca se ejecutan cubre el resto.

Un timer y lo que añade

# /etc/systemd/system/site-cron.service
[Unit]
Description=Site maintenance

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/var/www/site
ExecStart=/usr/bin/php cron.php

# /etc/systemd/system/site-cron.timer
[Unit]
Description=Run site maintenance nightly

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now site-cron.timer
systemctl list-timers --all
journalctl -u site-cron -n 50

Lo que te da el timer

• Registros en el journal, con el código de salida, en cada ejecución.
• Sin solapamiento: una ejecución que sigue en marcha cuando toca la siguiente no arranca una segunda copia.
• Persistent=true: una ejecución perdida con la máquina apagada ocurre en el siguiente arranque.
• RandomizedDelaySec: una flota de servidores no golpea toda la misma API a las 03:15:00 en punto.

Cuál usar

Una tarea de una línea en una máquina: cron, y no le des más vueltas. Todo aquello cuyo historial necesites ver, todo lo que no debe ejecutarse dos veces y todo lo que importa si se pierde: un timer.