Cron Schedulers y Timers de Systemd

1. Visión general del concepto y problema sistémico

Las aplicaciones web y los sistemas de agentes no pueden realizar todas las operaciones dentro de un ciclo de procesamiento de solicitudes HTTP sincrónico: cálculos prolongados, indexación de bases de código, generación de informes contables, copias de seguridad regulares de bases de datos y consultas a APIs externas llevarán a tiempos de espera en el navegador y degradación de la interfaz.

La solución clásica es delegar operaciones en segundo plano a ejecuciones programadas. Sin embargo, el uso ingenuo de la programación a menudo conduce a fallos en producción:

• Acumulación de tareas (Job Pileup): cuando la base de datos se ralentiza temporalmente, una nueva instancia del script se inicia antes de que la anterior haya finalizado, acumulando cientos de procesos colgados que pueden colapsar el servidor.
• Fallos silenciosos (Silent Failures): los errores de ejecución del cron tradicional se envían por defecto al correo local /var/mail/root, que nadie revisa, ocultando el hecho de que las copias de seguridad no se han realizado durante meses.

Cron Schedulers y Timers son un subsistema de infraestructura fundamental que garantiza la ejecución determinista, confiable y controlada de procesos en segundo plano con registro centralizado, limitación de recursos y exclusión mutua.

2. Taxonomía arquitectónica y modelo mental

El paisaje de los planificadores de tareas se divide en tres niveles de aislamiento y confiabilidad:

┌─────────────────────────────────────────────────────────────┐
│                 MATRIZ DE INFRAESTRUCTURA DE PLANIFICADORES │
├─────────────────────────────────────────────────────────────┤
│ 1. Nivel Nativo del Sistema Operativo                       │
│    • Linux Cron / Crontab (Verificación cada minuto /etc/cron*) │
│    • Timers de Systemd (.timer + .service con cgroups y logs) │
├─────────────────────────────────────────────────────────────┤
│ 2. Nivel de Aplicación y Cola Distribuida                  │
│    • Colas en memoria / Worker (BullMQ, Redis, Celery)      │
│    • Motores de Ejecución Duraderos (Flujos de Trabajo de Temporal, Inngest) │
├─────────────────────────────────────────────────────────────┤
│ 3. Nivel de Disparadores Serverless y en la Nube           │
│    • Disparadores Cron de Cloudflare / AWS EventBridge      │
│    • Monitores de Latido Externos (Healthchecks.io)        │
└─────────────────────────────────────────────────────────────┘

1. Timers de Systemd (Estándar moderno de Linux):
   • Compuestos por dos unidades: app-backup.service (comando de ejecución y limitaciones de recursos) y app-backup.timer (programación de ejecución). Proporcionan reinicio en caso de fallos y guardan logs en journald.
2. Colas Distribuidas (Distributed Job Queues):
   • Necesarias en clústeres de múltiples servidores, donde la tarea debe ser ejecutada por exactamente un worker en el sistema (Elección de Líder a través de Redis o base de datos).
3. Mecanismo de Exclusión Mutua (Mutual Exclusion via Flock):
   • Llamada del sistema o utilidad que crea un descriptor de archivo de bloqueo. Si la instancia anterior sigue viva, el nuevo proceso se cierra inmediatamente sin cargar el sistema.
4. Monitoreo de Latido (Dead Man's Snitch / Heartbeat):
   • Principio de control donde el script al final de su ejecución exitosa envía un ping HTTP a un monitoreo externo. Si la señal no se recibe en un intervalo de tiempo determinado, un ingeniero de guardia recibe alertas.

3. Pipeline técnico y mecánica interna

Ciclo de vida de una tarea periódica con control de confiabilidad:

1. Evaluación de la expresión cron (Cron Expression Matching): El planificador analiza cada minuto una expresión de 5 posiciones: $$\text{Minuto (0-59)} \quad \text{Hora (0-23)} \quad \text{Día (1-31)} \quad \text{Mes (1-12)} \quad \text{Día de la semana (0-6)}$$
2. Intento de adquisición de bloqueo (Flock Lock Acquisition): El script se invoca a través de una utilidad del sistema:

   flock -n /var/run/backup.lock /usr/local/bin/backup.sh
   

   Si el archivo está bloqueado por otro proceso, sale con código 0 sin conflicto.
3. Inicialización del entorno completo: El script importa explícitamente las variables de entorno o se ejecuta con una declaración completa de rutas:

   export PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
   

4. Ejecución de la tarea de ingeniería: El proceso realiza trabajo útil, dirigiendo la salida STDOUT y STDERR a un log o archivo de rotación.
5. Envío de señal de éxito (Heartbeat Ping): En caso de finalización exitosa, se envía una señal al monitoreo:

   curl -fsS -m 10 --retry 3 https://hc-ping.com/YOUR-UUID
   

6. Liberación del bloqueo: El descriptor de archivo se cierra, los recursos se liberan.

4. Escenarios prácticos de ingeniería en producción

01. Copia de seguridad de PostgreSQL en S3 a través de Timer de Systemd

Configuración de una copia de seguridad diaria confiable sin PaaS externos:

• Se crea la unidad /etc/systemd/system/pg-backup.service:

  [Unit]
  Description=Copia de Seguridad Nocturna de PostgreSQL en S3
  After=network-online.target
  
  [Service]
  Type=oneshot
  User=postgres
  ExecStart=/usr/local/bin/pg-backup-to-s3.sh
  MemoryMax=2G
  

• Se crea el timer /etc/systemd/system/pg-backup.timer:

  [Timer]
  OnCalendar=*-*-* 03:00:00
  Persistent=true
  
  [Install]
  WantedBy=timers.target
  

• La bandera Persistent=true garantiza que si el servidor estaba apagado a las 3:00 AM, la copia de seguridad se ejecutará inmediatamente después de encenderlo.

02. Reindexación horaria de la base de código para asistentes de IA

Mantenimiento de un índice vectorial fresco del repositorio:

• Un script verifica cada hora el comando git fetch. Si hay nuevos commits, se inicia un worker ligero que genera nuevos embeddings solo para los archivos modificados y actualiza las tablas SQLite-vec.

03. Limpieza segura de sesiones y logs antiguos (Rotación de Logs)

Prevención del desbordamiento del almacenamiento del sistema:

• Cron ejecuta cada noche una utilidad para eliminar cargas temporales mayores a 48 horas:

  find /var/www/uploads/tmp -type f -mtime +2 -delete
  

5. Errores comunes, trampas y seguridad

• Falta de rutas absolutas en los comandos: La entrada node server.js en crontab fallará con el error command not found. Siempre especifique la ruta exacta: /home/deploy/.nvm/versions/node/v22.0.0/bin/node /var/www/app/server.js.
• Confusión con las zonas horarias (UTC vs. Hora Local): Los servidores están configurados por defecto en UTC. Si programas una ejecución a las 04:00 hora de Kiev sin tener en cuenta el desfase, la tarea se ejecutará a las 06:00 o 07:00, cuando la carga del sistema ya esté en su punto máximo.
• Falta de timeouts en llamadas de red: Si un script dentro de cron hace curl a un servidor externo sin la bandera --max-time 30, un socket colgado puede bloquear el proceso durante semanas.
• Esperanza ciega en crontab sin verificar logs: Verifica periódicamente la funcionalidad de las tareas en segundo plano a través de grep CRON /var/log/syslog o configura alertas automáticas en caso de fallos.