cron vs systemd timers: automatizar su VPS Linux

Un VPS es un servidor que funciona de forma continua, a menudo sin supervisión humana directa. Precisamente por eso la automatización de las tareas recurrentes es fundamental: nadie estará ahí a las 3 de la madrugada para lanzar la copia de seguridad o renovar el certificado Let's Encrypt. Una tarea olvidada puede traducirse en una pérdida de datos, en un certificado caducado que deja el sitio fuera de línea o en un disco saturado por falta de rotación de logs. Las dos grandes herramientas disponibles en Linux —cron y los systemd timers— permiten planificar estas operaciones de forma fiable. Antes de elegir, conviene entender qué aporta realmente cada una.

Cron está presente en casi todos los sistemas Linux. Para planificar una tarea se edita la crontab del usuario actual con crontab -e. La sintaxis se basa en cinco campos separados por espacios: minuto, hora, día del mes, mes y día de la semana, seguidos del comando. Por ejemplo, 0 3 * * * /usr/local/bin/backup.sh ejecuta el script todos los días a las 3. Los ficheros depositados en /etc/cron.d/ pertenecen al sistema y pueden indicar el usuario de ejecución directamente en la línea. La salida estándar y la de error se envían por correo al usuario —algo que en la práctica se suele ignorar— o se redirigen manualmente a un fichero. Cron no conserva ningún historial nativo de las ejecuciones pasadas y no gestiona las tareas perdidas si la máquina estaba apagada.

Un timer de systemd es una pareja de dos ficheros de unidad: un fichero .service que describe qué ejecutar y un fichero .timer que describe cuándo lanzarlo. El timer se activa con systemctl enable --now monservice.timer y lo gobierna el gestor de servicios, exactamente igual que cualquier otro servicio de systemd. La directiva OnCalendar= acepta una sintaxis rica: daily, Mon *-*-* 03:00:00, *:0/15 (cada 15 minutos). También se pueden usar OnBootSec= y OnUnitActiveSec= para retardos relativos al arranque o a la última ejecución. Todas las salidas pasan por journald y se pueden consultar con journalctl -u monservice.service. El comando systemctl list-timers muestra la lista de todos los timers activos, su próximo vencimiento y la fecha de su última activación.

Cron sigue siendo la buena elección en varias situaciones. En sistemas antiguos o minimalistas sin systemd —algunos contenedores, BSD, imágenes Alpine— cron suele ser la única herramienta disponible. En un entorno multiusuario donde cada usuario gestiona sus propias tareas con crontab -e, cron es más sencillo de delegar sin conceder permisos de root. Para scripts muy simples de una sola línea, la crontab sigue siendo legible y mantenible sin crear dos ficheros de unidad. Por último, si su equipo está familiarizado con cron y las tareas funcionan sin problemas desde hace años, la migración no aporta necesariamente valor inmediato. El criterio decisivo es la necesidad de logs, de dependencias o de recursos acotados.

Los timers de systemd se imponen en cuanto la tarea supera el marco de un simple comando aislado. ¿Necesita journald para trazar cada ejecución, sus salidas y su código de retorno sin fontanería manual? Systemd timers. ¿Su script de copia de seguridad debe ejecutarse solo después de que PostgreSQL esté listo (After=postgresql.service)? Systemd timers. ¿Quiere limitar la memoria de un trabajo de sincronización para que no ahogue a los demás procesos (MemoryMax=512M)? Systemd timers. Y si el servidor se reinicia a las 2:58 cuando la copia de seguridad de las 3 tendría que haberse ejecutado, Persistent=true garantiza que se ejecutará en el siguiente arranque.

Tres problemas se repiten al poner en marcha los timers. Primer caso: el timer está activo pero nunca se dispara. Compruebe con systemctl list-timers que la columna NEXT muestra una fecha coherente, y que systemctl status backup.timer indica active (waiting). Un daemon-reload olvidado tras modificar un fichero de unidad es la causa número uno. Segundo caso: el servicio falla en silencio. Consulte journalctl -u monservice.service -n 50: allí están completos el código de retorno y la salida de error. Compruebe que la ruta de ExecStart= es absoluta. Tercer caso: la tarea no recupera las ejecuciones perdidas. Asegúrese de que Persistent=true está presente en el bloque [Timer].

Cron y los systemd timers conviven sin problema en el mismo servidor: no tiene que migrarlo todo de golpe. Conserve cron para sus tareas sencillas y sus scripts de usuario existentes, y adopte los timers de systemd para las nuevas automatizaciones que se benefician de los logs de journald, de las dependencias entre servicios o del aislamiento por cgroups. Los comandos systemd-analyze calendar y systemctl list-timers son sus mejores aliados para validar y supervisar sus planificaciones.