Cron vs Systemd Timer

83

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.
Faheem Mitha
quelle
4
"Cron wird garantiert in jedem Unix-ähnlichen System sein. Das wird sich nicht ändern." - Ich würde dies stark diskutieren. Während in der Vergangenheit Cron oft in der Grundkonfiguration von Unix-Installationen enthalten war, handelt es sich heutzutage auf den meisten Systemen lediglich um ein beliebiges optionales Softwarepaket. Tatsächlich gibt es mehrere beliebte Cron-Alternativen (z. B. Anacron, Fcron, Jobber), die Cron vorzuziehen sind. Die Funktionalität von cron ist für den Betrieb eines Systems nicht so wichtig wie systemd oder init. Wenn Sie sich also Gedanken über die aktuelle und zukünftige Portabilität machen, möchte ich lieber nicht darauf setzen.
Guido
6
Das ist eine ziemliche Liste von Dingen, die Sie in einer Antwort wollen. Vielleicht sollten Sie einige Zeit damit verbringen, die Werkzeuge selbst zu erlernen und herauszufinden, ob Sie diese Antworten selbst formulieren können. Wenn Sie bestimmte Dinge nicht verstehen, fragen Sie sie hier.
Larsks
5
Nicht wirklich. Ich habe alles gesagt, was ich zum Thema sagen möchte. Eine ausführliche Diskussion über alles, was systemd betrifft, zu führen, ist schlimmer als sinnlos. Einige sind der Meinung, dass die geringen Vorteile, die systemd mit sich bringt, die Unternehmensmonopolisierung des Linux-Ökosystems wert sind. Andere nicht.
cas
7
"Cron ist sehr alt und geht bis in die späten 1970er Jahre zurück." Faktisch korrekt, aber völlig irrelevant, solange die Pakete auf Ihrem System auf vernünftige und stabile Weise gewartet werden. Die Sonne ist auch sehr alt, aber ich hoffe, das heißt nicht, dass wir sie durch etwas Glänzenderes und Neueres ersetzen sollten.
Otheus
5
@Otheus Ich denke, dass Sie diesen Teil falsch verstehen - etwas zu sagen, das es schon lange gibt, ist keine Beleidigung. Zumindest für viele Unix-Leute. Es ist mehr so, als ob man sagt, ein Haus sei Hunderte von Jahren alt - das bedeutet sicherlich, dass es einige Probleme geben wird, einige Dinge sind seltsam, wenn sie nachgerüstet werden, aber es hat auch einen gewissen Charme und es muss gut gebaut worden sein. Es ist nicht baufällig zu sagen. Es ist ein einfaches Werkzeug, das sich seit vier Jahrzehnten bewährt hat.
Derobert

Antworten:

43

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.

F.sb
quelle
2
Das ist eine gute Anstrengung, danke. Ein direkterer Vergleich mit cron wäre jedoch hilfreich, einschließlich eines Beispiels. Außerdem ist einiges von dem, was Sie schreiben, nicht vollständig klar, z.
Faheem Mitha
Hallo, @F.SB! Ihre Antwort scheint zu implizieren, dass Sie Jobs in verschiedenen Zeitzonen planen können. Ist das richtig? Wie würdest du das machen? Es wäre ein erheblicher Vorteil gegenüber Standardimplementierungen von cron, aber ich konnte keine Informationen darüber finden, außer man systemd.timewas dem zu widersprechen scheint: Nicht-lokale Zeitzonen außer UTC werden nicht unterstützt.
Tad Lispy
Die Abhängigkeiten sind praktisch. Wenn die Hostsicherung beispielsweise als Systemzeitgeber ausgeführt wird, können Sie mithilfe von Abhängigkeiten sicherstellen, dass ein Datenbankexport unmittelbar vor der Sicherung abgeschlossen wird.
VK5TU
6
Seien Sie bitte ehrlicher. Sie beginnen damit, dass dies ein Punkt ist, an dem es um die beiden geht, und führen dann die Vorteile Ihrer bevorzugten Wahl auf . Es ist nicht schlecht, dass Sie eine Vorliebe haben, aber dann sollten Sie dies im Voraus angeben. Die Tatsache, dass alles zugunsten eines Systems ist und sich nicht mit den Vorteilen dieses Systems befasst, lässt mich das Gefühl haben, dass diese Antwort schief geht.
Jasper
2
@jasper lieber ich benutze beide basierend auf meinen bedürfnissen und es ist immer deine wahl, eine zu wählen basierend auf deinen bedürfnissen, ich erwähnte nur einige fakten basierend auf docs und handbüchern.
6.
16

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 =.
shdwlynx
quelle
6
Errr ... Ich bin mir nicht sicher, wie ich eine Antwort finde, die fast nur aus Kopieren und Einfügen besteht, zumal die Lizenzen nicht kompatibel sind. Aber zumindest sollten Sie das Bit "siehe nächster Abschnitt" korrigieren. Mit diesem Fehler fühlt es sich an, als hättest du nicht gelesen, was du kopiert und eingefügt hast.
Derobert