Me encantan los temporizadores de systemd

Ventajas percibidas de los temporizadores de systemd

• Muchos comentaristas han migrado la mayoría o todos los trabajos de cron a temporizadores de systemd, especialmente para copias de seguridad y tareas de mantenimiento.
• Los temporizadores pueden ser “persistentes”: si el sistema está caído a la hora programada, el trabajo se ejecuta una vez en el siguiente arranque.
• La integración con unidades de systemd proporciona registro por trabajo mediante journalctl, activación manual sencilla (systemctl start …) y entornos coherentes entre temporizadores y servicios.
• Funciones como RandomizedOffsetSec= y el jitter estable por host ayudan a evitar picos de carga de “tormenta de arranque” en muchas máquinas.
• La especificación temporal admite zonas horarias y expresiones de calendario más ricas que el cron clásico.
• Algunos elogian las funciones de seguridad y sandboxing disponibles del lado del servicio (namespaces, capabilities, UIDs aleatorios), viéndolas como más simples que los contenedores para muchos demonios.
• La activación por socket se destaca como potente para iniciar servicios bajo demanda y aislar el acceso de red.

Comparaciones con cron (y variantes)

• Cron se considera más simple para trabajos triviales de “ejecutar cada N minutos” y muy tangible (crontab -e, una línea, listo).
• Otros encuentran cron notoriamente frágil: entorno diferente, problemas con $PATH, salida que desaparece salvo que se capture explícitamente y depuración complicada.
• Algunos señalan que cron ya tiene extensiones como @reboot, recuperación al estilo anacron, RANDOM_DELAY y CRON_TZ, argumentando que las ventajas de systemd son menores de lo que se afirma y no universales entre implementaciones de cron.

Sintaxis, configuración y herramientas

• Debate sobre la sintaxis de las unidades de systemd: algunos consideran que los archivos al estilo INI son limpios y mínimos; otros los encuentran feos y desearían YAML, XML o TOML.
• Se corrigen conceptos erróneos (por ejemplo, se permiten espacios alrededor de =; Environment= puede contener múltiples variables).
• A los usuarios de NixOS les gusta definir unidades de forma declarativa en Nix, con comprobación de tipos y composición; los críticos encuentran esa representación más fea y echan de menos secciones explícitas [Unit]/[Service]/[Timer].
• Los temporizadores que requieren un archivo .service y otro .timer se ven a la vez como flexibles y molestamente verbosos.

Fiabilidad, complejidad y críticas

• Varios comentarios elogian la robustez y la documentación de systemd frente a los viejos scripts de init y cron.
• Otros relatan errores graves (por ejemplo, un temporizador de logrotate que silenciosamente nunca se ejecutaba) y acusan a systemd de una alta complejidad accidental y de una mala respuesta de los mantenedores ante casos límite.
• Preocupaciones arquitectónicas más amplias: systemd como un monolito en crecimiento constante, “embrace and extend” de herramientas existentes y miedo al bloqueo por proveedor.

Ecosistema, portabilidad y alternativas

• Algunos administradores prefieren o necesitan cron en BSD, Alpine o Linux sin systemd, o usan programadores alternativos (mcron, ejecutores de trabajos personalizados).
• Consenso general: los temporizadores son excelentes en sistemas con systemd, pero cron sigue siendo válido, especialmente donde systemd no existe o no es bienvenido.