Scheduling aus Entwicklersicht: Cron und/oder Systemd

[buhtz]

Ich bin Teil des Maintainer Teams einer Anwendung, die im Hintergrund sehr intensiv Gebrauch macht von cron (und auch anacron).
In dem Kontext lese ich derzeit häufiger, man solle das ja jetzt mit systemd erledigen, weil cron ja bald tot sei.

Mir geht es hier nicht um eine pro/contra Bewertung beider Varianten. Als Entwickler muss ich nehmen, was mir das System offeriert.
Vermeiden möchte ich jedoch unbedingt, dass ich hier zwei Systeme unterstütze und mein Code entsprechend komplex wird.

Ich denke es eilt nicht, weshalb ich vorerst bei cron bleiben kann. Aber wie schätzt ihr die Entwicklung ein? Bei Debian gehe ich ja stark davon aus, dass hier lange beides im System bleiben wird. Aber bei Fedora soll cron angeblich schon per default deaktiviert sein. Natürlich gibt es auch systemd-freie Distros, die ich nicht vergessen möchte.

Wie schätzt ihr die Situation derzeit ein?

[schorsch_76]

Das cron stirbt oder aus Debian entfernt wird glaube ich ehrlich gesagt nicht. Wenn es nicht mehr in der Standardinstallation einiger Distributionen nicht mehr installiert sein könnte, kann ich mir vorstellen aber auch dort wird es im Packetmanagement verfügbar bleiben. Es gibt ja nicht nur eine cron Implementierung. Da gibt es ja etliche Versionen bzw. Implementierungen [1]

[1] https://wiki.gentoo.org/wiki/Cron#Which ... the_job.3F

[Meillo]

Fuer die aufgerufenen Programme und Scripte macht es ja keinen Unterschied. Geht es dir also um automatisches Eintragen von Jobs? Oder an welcher Stelle genau betrifft das deine Arbeit?

Aus meiner Sicht sollte es keinen grossen Unterschied machen, ob ihr die Jobs mit Cron oder mit Systemd aufrufen lasst. Selbst wenn ihr das Verwalten der Jobeintraege automatisiert habt, sollte das mit einer Abstraktionsebene einfach austauschbar sein. Aber vielleicht sehe ich den Problempunkt noch nicht ganz ...

(Edit: Aus meiner Sicht sollte deine Anwendung *nicht* komplexer werden, wenn du beide Systeme unterstuetzt. Es gibt nur wenige Aktionen, die mit Jobs gemacht werden koennen, und die lassen sich sehr gut kapseln und abstrahieren. Falls du dafuer noch keine Abstraktionsschicht hast, wird's Zeit, diese auch unabhaengig der aktuellen Frage einzufuehren. Wenn du diese Schicht schon hast, dann schreibst du einfach eine zweite Implementierung des Interfaces. Die Komplexitaet des Gesamtsystems erhoeht sich dadurch so gut wie nicht. Es erhoehen sich nur die Supportszenarien.)


Zur Frage, wie ich denke, dass die Zukunft wird: Cron wird noch laaaange Zeit installierbar sein. Ob es bei einer neuen Installation standardmaessig installiert ist, ist IMO egal.

[paedubucher]

Es stellt sich die Frage, wie stark ihr sonst auf systemd setzt. Habt ihr beispielsweise dateibasierte Trigger im Einstatz (z.B. Aktionen, die beim Beschreiben eines serverseitigen Git-Repos ablaufen)? Dann wäre es naheliegend, auch zeitliche Trigger (Cronjobs) mit systemd zu managen.

Oder habt ihr ein Deployment, wo irgendwo noch ein anderes Unix involviert ist? Wir haben beispielsweise noch einen FreeBSD-Server, und ich bin doch recht froh, dass wir im Konfigurationsmanagementtool nur einen Mechanismus (cron) unterstützen müssen.

systemd bietet einige recht komfortable Features, wie beispielsweise neulich wegen Sommer- und Winterzeit diskutiert. (Das ist gerade dann interessant, wenn man auf dem Server noch UTC verwendet.) Vielleicht gibt es Anforderungen, die man mit systemd einfacher bedienen kann als mit cron.