Cron vs systemd timers

On m'a récemment signalé qu'il existait une alternative au logiciel cron, à savoir les timers système.

Cependant, je ne connais rien aux timers systemd ou systemd. Je n'ai utilisé que cron.

Il y a une petite discussion dans Arch Wiki . Cependant, je cherche une comparaison détaillée entre les cronminuteries système et systemd, en mettant l'accent sur les avantages et les inconvénients. J'utilise Debian, mais j'aimerais une comparaison générale de tous les systèmes pour lesquels ces deux alternatives sont disponibles. Cet ensemble peut inclure uniquement les distributions Linux.

Voici ce que je sais

Cron est très vieux et remonte à la fin des années 1970. L'auteur original de cron est Ken Thompson, le créateur d'Unix. Vixie cron, dont les crons dans les distributions Linux modernes sont des descendants directs, date de 1987.

Systemd est beaucoup plus récent et quelque peu controversé. Wikipedia m'a dit que sa publication initiale était le 30 mars 2010.

Ainsi, ma liste actuelle des avantages des temporisateurs cron sur systemd est la suivante:

1. Il est garanti que Cron se trouve dans n’importe quel système de type Unix, en ce sens qu’il s’agit d’un logiciel compatible pouvant être installé. Cela ne va pas changer. En revanche, systemd peut rester ou non dans les distributions Linux à l’avenir. Il s’agit principalement d’un système init et peut être remplacé par un autre système init.

2. Cron est simple à utiliser. Certainement plus simple que les timers systemd.

La liste correspondante des avantages des timers systemd sur cron est la suivante:

1. Les temporisateurs Systemd peuvent être plus flexibles et capables. Mais j'aimerais des exemples de cela.

Donc, pour résumer, voici certaines choses qu’il serait bon de voir dans une réponse:

1. Une comparaison détaillée des timers cron et systemd, y compris les avantages et les inconvénients de l’utilisation de chacun.
2. Exemples de choses que l'on peut faire et que l'autre ne peut pas faire.
3. Au moins une comparaison côte à côte d'un script cron avec un script timers systemd.

Voici quelques points à propos de ces deux :

1. vérifier ce que fait réellement votre travail cron peut être un peu un fouillis, mais tous les événements de minuterie systemd sont soigneusement consignés dans le journal systemd comme les autres unités systemd basées sur l'événement qui facilite grandement les choses.

2. Les timers systemd sont des services systemd avec toutes leurs capacités en matière de gestion des ressources, de planification de processeurs d'E / S, ...
   Il existe une liste:
   

   • filtres d'appels système
     
   • identifiants utilisateur / groupe
     
   • contrôle d'adhésion
     
   • belle valeur
     
   • Score de MOO
     
   • Classe et priorité de programmation d'E / S
     
   • Politique de planification du processeur CPU
     
   • affinité umask
     
   • pantalon minuterie
     
   • bits sécurisés
     
   • accès réseau et, ...
     

3. Avec l'option Dépendances, tout comme les autres services Systemd, il peut exister des dépendances sur l'heure d'activation.
   

4. Les unités peuvent être activées de différentes manières, et leur combinaison peut également être configurée. les services peuvent être démarrés et déclenchés par différents événements tels que l'utilisateur, le démarrage, les modifications de l'état du matériel ou, par exemple, 5 minutes après le branchement de certains éléments matériels, et ...

5. configuration beaucoup plus facile de certains fichiers et balises simples pour effectuer diverses personnalisations en fonction de vos besoins avec des minuteries systemd.

6. Activez / désactivez facilement le tout avec:

   systemctl enable/disable 
   

   et tuer tous les enfants de l'emploi avec:

   systemctl start/stop
   

7. Les minuteries systemd peuvent être programmées avec des calendriers et des heures monotones, ce qui peut s'avérer très utile dans le cas de fuseaux horaires différents, et ...

8. Les événements temporels de systemd (calendrier) sont plus précis que cron (semble une précision de 1s)

9. Les événements time de systemd sont plus significatifs, pour ceux qui se répètent ou même ceux qui devraient se produire une fois, voici un exemple tiré du document :

   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. Du point de vue de l'utilisation du processeur, systemd timer réveille le processeur pendant le temps écoulé, mais cron le fait plus souvent.

11. Les événements du minuteur peuvent être planifiés en fonction des heures de fin des exécutions. Certains délais peuvent être définis entre les exécutions.

12. La communication avec d’autres programmes est également remarquable. Il est parfois nécessaire que certains autres programmes connaissent les minuteries et l’état de leurs tâches.

Directement de la bouche du cheval, pour ainsi dire: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

Un extrait de la page ci-dessus:

Avantages

Les principaux avantages de l'utilisation de minuteries proviennent du fait que chaque travail possède son propre service systemd. Certains de ces avantages sont:

• Les travaux peuvent être facilement lancés indépendamment de leurs minuteries. Cela simplifie le débogage.
• Chaque travail peut être configuré pour s'exécuter dans un environnement spécifique (voir systemd.exec (5)).
• Les travaux peuvent être attachés à des groupes de contrôle.
• Les tâches peuvent être configurées pour dépendre d'autres unités systemd.
• Les travaux sont consignés dans le journal systemd pour faciliter le débogage.

Mises en garde

Certaines choses faciles à faire avec cron sont difficiles à faire avec les unités de minuterie seules.

• Complexité: pour configurer un travail chronométré avec systemd, vous créez deux fichiers et exécutez deux commandes systemctl. Comparez cela à l'ajout d'une seule ligne à une crontab.
• Emails: il n'y a pas d'équivalent intégré à MAILTO de cron pour l'envoi d'emails en cas d'échec du travail. Voir la section suivante pour un exemple de configuration d'un équivalent avec OnFailure =.