Timers de systemd vs cron: cuándo elegir qué

Le tengo cariño a cron. Son dos caracteres de sintaxis que tengo que mirar cada seis meses, pero el archivo se edita con nano, el lenguaje es el mismo en cualquier Linux desde 2003 hasta hoy, y cuando algo falla, falla como fallan las cosas viejas de Unix: en silencio, en tu inbox.

Los timers de systemd son lo opuesto. Verbosos, estructurados, integrados con el init, hermosamente observables. Y la sintaxis no la miras porque la man page está justo ahí.

Tras años operando ambos, esto es cuándo se gana cada uno su sitio.

Usa cron cuando

• El job es una línea y el sistema es una caja. Un dump nocturno de la base de datos, un trigger estilo /etc/letsencrypt/renewal-hooks/. Dos minutos para escribirlo, dos para olvidarlo.
• Necesitas que funcione igual en cualquier distro durante diez años. Cron es la lingua franca. Si tu script tiene que correr en un Debian de 2015, un Alpine de 2024 y un NAS Synology, cron es el mínimo común denominador. Los timers de systemd existen en la mayoría de distros modernas, pero no en todas.
• El fallo es aceptable o visible por otra vía. Si el cron escribe a una cola que tiene su propia monitorización y el modo de fallo es “la cola se atrasa un poco, alguien se da cuenta en 10 minutos”, cron está bien.

Usa timers de systemd cuando

• El job forma parte de un servicio real. Backups, rotación de logs, rotación de certificados, consumidores de cola que despiertan periódicamente. Cualquier cosa donde el timer es el disparador y la unit es el trabajo, y ese trabajo puede ser un proceso de varios minutos con dependencias, variables de entorno, namespaces o políticas de reinicio. El modelo de unidades de systemd es un modelo de verdad. El entorno de cron es una postal.
• Quieres observabilidad sin inventarla. systemctl list-timers, journalctl -u myjob.timer, systemctl status myjob.service. Ves la última ejecución, la próxima, el código de salida, la salida, todo en un sitio. No hay que enviar logs a ningún sitio; el journal está ahí.
• El job depende de otras units. “Ejecuta después de que la red esté arriba”, “ejecuta cuando el servicio de base de datos esté sano”, “no ejecutes si el disco cifrado no está montado” — son una línea en systemd y una pesadilla en cron.
• Necesitas el comportamiento de cron pero con offset aleatorio para evitar el thundering herd. RandomizedDelaySec es la feature que desearías que cron tuviera.

Tres reglas que aplico ya en automático

1. Si un job vive dentro de una aplicación que despliego, va en systemd. Despliega con la app, monitoriza con la app, y cuando la app hace rollback, el timer también.
2. Si un job es “el SO recordándome hacer una cosa pequeña en este servidor”, va en cron. Renovaciones de letsencrypt, limpieza de directorios de log, cosas donde la existencia del cronfile es la documentación.
3. Elija lo que elija, va a control de versiones. /etc/cron.d/myjob y /etc/systemd/system/myjob.timer son ambos archivos. Ambos van en el mismo repo Ansible/Salt/lo-que-uses. La frontera es “el paquete de este servidor”, no “la sintaxis de esta herramienta”.

La verdad poco glamurosa: la mayoría de equipos toman esta decisión por feeling, se arrepienten, y aun así acumulan ambos durante diez años. Elige deliberadamente, opera ambos donde se ganen el sitio, y deja de fingir que uno de los dos va a desaparecer.