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:

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.
Cron est simple à utiliser. Certainement plus simple que les timers systemd.

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

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:

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

cron systemd-timer

— Faheem Mitha
source

"Cron est garanti sur n'importe quel système de type Unix. Cela ne changera pas." - Je voudrais en débattre fortement. Alors qu'historiquement cron a souvent été inclus dans la configuration de base des installations Unix, sur la plupart des systèmes actuels, il s'agit simplement d'un progiciel optionnel parmi d'autres. En fait, il existe plusieurs alternatives cron populaires (par exemple, anacron, fcron, jobber) qui peuvent être préférables à cron. La fonctionnalité de cron n'est pas essentielle au fonctionnement d'un système, contrairement à systemd ou init, donc si vous êtes préoccupé par la portabilité actuelle et future, je préférerais ne pas y placer mes paris.

— Guido

C'est toute une liste de choses que vous voulez dans une réponse. Je pense que vous devriez peut-être passer un peu de temps à apprendre vous-même les outils et voir si vous pouvez formuler ces réponses vous-même, et si vous avez des problèmes spécifiques que vous ne comprenez pas, posez-les ici.

— larsks

Pas vraiment. J'ai dit tout ce que je voulais dire sur le sujet. S'engager dans une discussion approfondie sur tout ce qui concerne systemd est pire que inutile - certains pensent que les avantages mineurs apportés par systemd valent la monopolisation par les entreprises de l'écosystème linux. Les autres non.

— cas

"Cron est très vieux et remonte à la fin des années 1970." Factuellement correct, mais complètement inutile tant que les packages de votre système sont maintenus de manière raisonnable et stable. Le soleil est aussi très vieux, mais j'espère que cela ne signifie pas que nous devrions le remplacer par quelque chose de plus brillant et de plus récent.

— Otheus le

@Otheus Je pense que vous prenez cette partie de la main mal: dire que quelque chose existe depuis longtemps n'est pas une insulte. Au moins pour beaucoup de gens Unix. C'est plus comme dire qu'une maison a des centaines d'années - cela signifie certainement qu'elle aura des problèmes, que certains travaux seront bizarres lors de la rénovation, mais elle a aussi un certain charme et elle a dû être bien construite. Cela ne veut pas dire sa décrépit. C'est un outil simple qui s'est révélé utile pendant quatre décennies.

— derobert

Réponses:

Voici quelques points à propos de ces deux :

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.
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, ...
Avec l'option Dépendances, tout comme les autres services Systemd, il peut exister des dépendances sur l'heure d'activation.
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 ...
configuration beaucoup plus facile de certains fichiers et balises simples pour effectuer diverses personnalisations en fonction de vos besoins avec des minuteries systemd.
Activez / désactivez facilement le tout avec:
```
systemctl enable/disable 
```
et tuer tous les enfants de l'emploi avec:
```
systemctl start/stop
```
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 ...
Les événements temporels de systemd (calendrier) sont plus précis que cron (semble une précision de 1s)

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

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.
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.
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.

— F.sb
source

C'est un bon effort, merci. Cependant, des comparaisons plus directes avec cron seraient utiles, y compris un exemple. En outre, une partie de ce que vous écrivez n'est pas tout à fait claire, par exemple, "du point de vue de l'utilisation du processeur, le temporisateur systemd réveille le processeur pendant le temps écoulé, mais le cron le fait plus souvent".

— Faheem Mitha

Bonjour, @ F.SB! Votre réponse semble impliquer que vous pouvez planifier des tâches en utilisant différents fuseaux horaires. Est-ce correct? Comment feriez-vous cela? Ce serait un avantage significatif par rapport aux implémentations standard de cron, mais je n’ai trouvé aucune information à ce sujet, à l’exception de man systemd.timece qui semble le contredire: les fuseaux horaires non locaux, à l’exception de l’UTC, ne sont pas pris en charge.

— Tad Lispy

Les dépendances sont pratiques. Par exemple, si la sauvegarde de l'hôte s'exécute en tant que timer systemd, vous pouvez utiliser des dépendances pour vous assurer que l'exportation de la base de données se termine immédiatement avant la sauvegarde.

— Vk5tu

S'il vous plaît soyez plus honnête à l'avant. Vous commencez par dire qu’il s’agit d’un point sur les deux, puis vous continuez en énumérant les avantages de votre choix . Ce n’est pas mal que vous ayez une préférence, mais alors vous devriez le dire dès le départ. En plus de cela, le fait que tout soit en faveur d'un système et ne regarde pas les avantages de ce système me fait penser que cette réponse est biaisée.

— Jasper

@jasper cher, j'utilise les deux en fonction de mes besoins, et c'est toujours votre choix d'en choisir un en fonction de vos besoins. Je viens de mentionner quelques faits basés sur des documents et des manuels.

— F.sb

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 =.

— shdwlynx
source

Euh ... je ne sais pas trop ce que je pense d'une réponse presque entièrement copiée-collée, d'autant plus que les licences ne sont pas compatibles. Mais au minimum, vous devriez corriger ce bit "voir la section suivante". Avec cette erreur, vous avez l'impression de ne pas avoir lu ce que vous avez copié et collé.

— derobert

Lorsque vous citez des documents provenant de quelque part, vous devez citer la source et indiquer clairement ce qui est cité . Le plagiat n'est pas cool .

— Gilles