Cron vs Systemd Timer

Vor kurzem wurde ich darauf hingewiesen, dass es eine Alternative zu Cron gibt, nämlich System-Timer.

Allerdings weiß ich nichts über Systemd oder Systemd Timer. Ich habe nur Cron verwendet.

Es gibt eine kleine Diskussion im Arch Wiki . Ich bin jedoch auf der Suche nach einem detaillierten Vergleich zwischen cronund System-Timern, wobei ich mich auf die Vor- und Nachteile konzentriere. Ich benutze Debian, möchte aber einen allgemeinen Vergleich für alle Systeme, für die diese beiden Alternativen verfügbar sind. Dieser Satz kann nur Linux-Distributionen enthalten.

Hier ist was ich weiß.

Cron ist sehr alt und geht bis in die späten 1970er Jahre zurück. Der ursprüngliche Autor von cron ist Ken Thompson, der Schöpfer von Unix. Vixie Cron, von dem die Cron in modernen Linux-Distributionen direkte Nachfahren sind, stammt aus dem Jahr 1987.

Systemd ist viel neuer und etwas umstritten. Wikipedia teilt mir mit, dass die Erstveröffentlichung am 30. März 2010 war.

Meine aktuelle Liste der Vorteile von Cron gegenüber System-Timern ist:

1. Es wird garantiert, dass Cron in jedem Unix-ähnlichen System vorhanden ist, im Sinne einer installierbaren unterstützten Software. Das wird sich nicht ändern. Im Gegensatz dazu kann systemd in Zukunft in Linux-Distributionen verbleiben oder nicht. Es ist hauptsächlich ein Init-System und kann durch ein anderes Init-System ersetzt werden.

2. Cron ist einfach zu bedienen. Auf jeden Fall einfacher als systemd Timer.

Die entsprechende Liste der Vorteile von systemd-Timern gegenüber cron lautet:

1. Systemd-Timer sind möglicherweise flexibler und leistungsfähiger. Aber ich möchte Beispiele dafür.

Zusammenfassend sind hier einige Dinge, die in einer Antwort zu sehen sind:

1. Ein detaillierter Vergleich von Cron- und Systemd-Timern, einschließlich der Vor- und Nachteile der einzelnen Timer.
2. Beispiele für Dinge, die ein anderer nicht kann.
3. Mindestens ein Side-by-Side-Vergleich eines Cron-Skripts mit einem System-Timer-Skript.

Hier sind einige Punkte zu diesen beiden :

1. zu überprüfen, was Ihr Cron-Job wirklich macht, kann eine Art Chaos sein, aber alle System-Timer-Ereignisse werden sorgfältig im System-Journal protokolliert, wie die anderen System-Einheiten, basierend auf dem Ereignis, das die Dinge viel einfacher macht.

2. Systemd-Timer sind Systemd-Services mit all ihren Funktionen für Ressourcenmanagement, IO-CPU-Scheduling, ...
   Es gibt eine Liste:
   

   • Systemcall-Filter
     
   • Benutzer- / Gruppen-IDs
     
   • Mitgliedschaftskontrollen
     
   • guter Wert
     
   • OOM-Punktzahl
     
   • IO-Scheduling-Klasse und -Priorität
     
   • CPU-Planungsrichtlinie CPU
     
   • Affinität umask
     
   • Timer läuft aus
     
   • sichere Bits
     
   • Netzwerkzugang und, ...
     

3. Mit der Option "Abhängigkeiten" können wie bei anderen systemd-Diensten Abhängigkeiten von der Aktivierungszeit bestehen.
   

4. Einheiten können auf verschiedene Arten aktiviert werden, auch Kombinationen können konfiguriert werden. Dienste können durch verschiedene Ereignisse gestartet und ausgelöst werden, z. B. durch Benutzer-, Boot- oder Hardwarestatusänderungen.

5. Viel einfachere Konfiguration einiger Dateien und einfacher Tags, um eine Vielzahl von Anpassungen basierend auf Ihren Anforderungen mit System-Timern vorzunehmen.

6. Aktivieren / Deaktivieren Sie das Ganze ganz einfach mit:

   systemctl enable/disable 
   

   und töte alle Kinder des Jobs mit:

   systemctl start/stop
   

7. systemd-Timer können mit Kalendern und monotonen Zeiten geplant werden, was bei unterschiedlichen Zeitzonen und ...

8. Systemzeitereignisse (Kalender) sind genauer als Cron (scheint 1s Genauigkeit)

9. Systemzeitereignisse sind aussagekräftiger. Für wiederkehrende Ereignisse oder sogar Ereignisse, die einmal auftreten sollten, ist hier ein Beispiel aus dem Dokument :

   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. Aus der Sicht der CPU-Auslastung weckt der System-Timer die CPU zur abgelaufenen Zeit, aber cron macht das öfter.

11. Timer-Ereignisse können basierend auf den Endzeiten von Ausführungen geplant werden. Zwischen den Ausführungen können einige Verzögerungen eingestellt werden.

12. Die Kommunikation mit anderen Programmen ist auch bemerkenswert. Manchmal ist es erforderlich, dass einige andere Programme Timer und den Status ihrer Aufgaben kennen.

Sozusagen direkt aus dem Maul des Pferdes: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

Ein Auszug aus der obigen Seite:

Leistungen

Die Hauptvorteile der Verwendung von Timern liegen darin, dass jeder Job über einen eigenen System-Service verfügt. Einige dieser Vorteile sind:

• Jobs können unabhängig von ihren Timern einfach gestartet werden. Dies vereinfacht das Debuggen.
• Jeder Job kann so konfiguriert werden, dass er in einer bestimmten Umgebung ausgeführt wird (siehe systemd.exec (5)).
• Jobs können an Gruppen angehängt werden.
• Jobs können so eingerichtet werden, dass sie von anderen Systemeinheiten abhängen.
• Jobs werden im systemd-Journal protokolliert, um das Debuggen zu vereinfachen.

Vorbehalte

Einige Dinge, die mit cron leicht zu tun sind, lassen sich nur schwer mit Zeitgebereinheiten tun.

• Komplexität: Um einen zeitgesteuerten Job mit systemd einzurichten, erstellen Sie zwei Dateien und führen einige systemctl-Befehle aus. Vergleichen Sie dies mit dem Hinzufügen einer einzelnen Zeile zu einer Crontab.
• E-Mails: Es gibt kein integriertes Äquivalent zu crons MAILTO zum Versenden von E-Mails bei Auftragsfehlern. Im nächsten Abschnitt finden Sie ein Beispiel für die Einrichtung einer Entsprechung mit OnFailure =.