Cron vs temporizadores systemd

Recientemente se me señaló que existe una alternativa al cron, a saber, los temporizadores systemd.

Sin embargo, no sé nada sobre los temporizadores systemd o systemd. Solo he usado cron.

Hay una pequeña discusión en Arch Wiki . Sin embargo, estoy buscando una comparación detallada entre los crontemporizadores y systemd, centrándome en los pros y los contras. Utilizo Debian, pero me gustaría una comparación general de todos los sistemas para los que estas dos alternativas están disponibles. Este conjunto puede incluir solo distribuciones de Linux.

Aquí está lo que sé.

Cron es muy viejo y se remonta a fines de la década de 1970. El autor original de cron es Ken Thompson, el creador de Unix. Vixie cron, del cual los crons en las distribuciones modernas de Linux son descendientes directos, data de 1987.

Systemd es mucho más nuevo y algo controvertido. Wikipedia me dice que su lanzamiento inicial fue el 30 de marzo de 2010.

Entonces, mi lista actual de ventajas de cron sobre temporizadores systemd es:

1. Cron está garantizado para estar en cualquier sistema similar a Unix, en el sentido de ser una pieza de software compatible instalable. Esto no va a cambiar. Por el contrario, systemd puede o no permanecer en las distribuciones de Linux en el futuro. Es principalmente un sistema init, y puede ser reemplazado por un sistema init diferente.

2. Cron es simple de usar. Definitivamente más simple que los temporizadores systemd.

La lista correspondiente de ventajas de los temporizadores systemd sobre cron es:

1. Los temporizadores de Systemd pueden ser más flexibles y capaces. Pero me gustaría ejemplos de eso.

Entonces, para resumir, aquí hay algunas cosas que sería bueno ver en una respuesta:

1. Una comparación detallada de los temporizadores cron vs systemd, incluidos los pros y los contras del uso de cada uno.
2. Ejemplos de cosas que uno puede hacer que el otro no.
3. Al menos una comparación lado a lado de un script cron frente a un script de temporizadores systemd.

Aquí hay algunos puntos sobre esos dos :

1. verificar lo que realmente hace su trabajo cron puede ser un desastre, pero todos los eventos del temporizador systemd se registran cuidadosamente en el diario systemd como las otras unidades systemd en función del evento que hace las cosas mucho más fáciles.

2. Los temporizadores systemd son servicios systemd con todas sus capacidades para la gestión de recursos, la programación de CPU de IO, ...
   Hay una lista:
   

   • filtros de llamada al sistema
     
   • ID de usuario / grupo
     
   • controles de membresía
     
   • buen valor
     
   • Puntaje OOM
     
   • Clase de programación IO y prioridad
     
   • Política de programación de CPU CPU
     
   • afinidad umask
     
   • pantalones de temporizador
     
   • bits seguros
     
   • acceso a la red y, ...
     

3. con la opción de dependencias al igual que otros servicios systemd, puede haber dependencias en el tiempo de activación.
   

4. Las unidades se pueden activar de diferentes maneras, también se puede configurar una combinación de ellas. los servicios pueden iniciarse y activarse por diferentes eventos como usuario, arranque, cambios de estado del hardware o, por ejemplo, 5 minutos después de que se conecte algún hardware y, ...

5. configuración mucho más fácil de algunos archivos y etiquetas directas para hacer una variedad de personalizaciones basadas en sus necesidades con temporizadores systemd.

6. Activa / desactiva fácilmente todo con:

   systemctl enable/disable 
   

   y matar a todos los hijos del trabajo con:

   systemctl start/stop
   

7. Los temporizadores systemd se pueden programar con calendarios y tiempos monótonos, lo que puede ser realmente útil en caso de diferentes zonas horarias y, ...

8. Los eventos de tiempo systemd (calendario) son más precisos que cron (parece precisión de 1)

9. Los eventos de tiempo de systemd son más significativos, para aquellos recurrentes o incluso aquellos que deberían ocurrir una vez, aquí hay un ejemplo del documento :

   Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00
     Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                   Wed *-1 → Wed *-*-01 00:00:00
           Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
                Wed, 17:48 → Wed *-*-* 17:48:00 
   

10. Desde el punto de vista del uso de la CPU, el temporizador systemd activa la CPU en el tiempo transcurrido, pero cron lo hace con más frecuencia.

11. Los eventos de temporizador se pueden programar en función de los tiempos de finalización de las ejecuciones, se pueden establecer algunos retrasos entre ejecuciones.

12. La comunicación con otros programas también es notable, a veces es necesario que otros programas conozcan los temporizadores y el estado de sus tareas.

Directamente de la boca del caballo, por así decirlo: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

Un extracto de la página de arriba:

Beneficios

Los principales beneficios del uso de temporizadores provienen de que cada trabajo tiene su propio servicio systemd. Algunos de estos beneficios son:

• Los trabajos se pueden iniciar fácilmente independientemente de sus temporizadores. Esto simplifica la depuración.
• Cada trabajo se puede configurar para ejecutarse en un entorno específico (consulte systemd.exec (5)).
• Los trabajos se pueden adjuntar a cgroups.
• Los trabajos se pueden configurar para depender de otras unidades systemd.
• Los trabajos se registran en el diario systemd para facilitar la depuración.

Advertencias

Algunas cosas que son fáciles de hacer con cron son difíciles de hacer solo con unidades de temporizador.

• Complejidad: para configurar un trabajo cronometrado con systemd, crea dos archivos y ejecuta un par de comandos systemctl. Compare eso con agregar una sola línea a un crontab.
• Correos electrónicos: no hay un equivalente incorporado al MAILTO de cron para enviar correos electrónicos por fallas en el trabajo. Consulte la siguiente sección para ver un ejemplo de configuración de un equivalente utilizando OnFailure =.