Paul Jarc’s software
▻http://code.dogmap.org.
Il y a surtout runwhen qui remplace cron.
Software packages
These are licensed under the GPL, but that doesn’t mean it’s necessarily a good idea for you to distribute modified versions. I’d like to know if you plan to do that.
fdtools is a set of utilities for working with file descriptors.
guile-ldap is an extension for GNU Guile providing bindings to the OpenLDAP client library.
idtools is a set of utilities for working with user and group IDs and other process parameters.
mkmed automatically generates package build scripts.
posterity is set of servers for publishing email archives.
prjlibs is set of general-purpose libraries for C, sh, and Scheme.
runwhen is a set of utilities for running commands at particular times.
spftools is a set of utilities for managing foreign slashpackage installations.
sptools is a set of utilities for managing slashpackage installations.
svclean lets you run daemontools with clean shutdown, and with supervised logging of svscan’s and supervise’s output.
▻https://wiki.uberspace.de/system:runwhen
Keine Kollisionen. Man kann diesen Punkt gar nicht oft genug betonen. Jeder, der schon einmal einen Cronjob verfasst hat, der z.B. alle fünf Minuten laufen sollte und der dann aber für einen Durchlauf länger als fünf Minuten braucht, hat gesehen, wie ärgerlich es ist, wenn mehrere Instanzen eines Cronjobs gleichzeitig laufen (nehmen wir zum Beispiel einen Job, der Newsletter verschickt, mit dem Versand aber eine Stunden beschäftigt ist und währenddessen alle fünf Minuten weitere Instanzen startet, die ebenfalls anfangen, den gleichen Newsletter an die gleichen Empfänger zu verschicken …).
Sekundengenaue Ausführung. Mit Cron können Jobs maximal minutengenau ausgeführt werden; runwhen arbeitet sekundengenau. Es ist also kein Problem, einen Job mehrmals in der Minute laufen zu lassen, beispielsweise, weil er die Verfügbarkeit eines Dienstes prüfen soll und Probleme nicht erst nach einer Minute bemerken soll.
Integriertes Logging. runwhen-Jobs laufen unter den daemontools und können sich dessen Fähigkeit, sämtliche Ausgaben direkt in einen Logging-Prozess zu schicken, zunutze machen.
Auskunft, wann die nächste Ausführung stattfindet. Unmittelbar beim Start wird ins Logfile geschrieben, wann die nächste Ausführung des Scripts zu erwarten ist. Damit siehst du sofort, ob das von dir gewählte Zeitschema korrekt angegeben wurde.
„Mach’s sofort“-Feature. Du hast jederzeit die Möglichkeit, einen Job jetzt sofort anzustoßen, ungeachtet der eigentlich geplanten Zeit. Dabei läuft der Job unter exakt der gleichen Umgebung wie sonst auch, was jeden freuen dürfte, der schon mal darüber gestolpert ist, dass unter Cron das Set an Umgebungsvariablen nicht völlig identisch zu dem der Login-Shell ist.
Temporäres Pausieren. Wie alle Jobs, die unter den Daemontools laufen, kannst du mit einem einzigen svc-Aufruf weitere Ausführungen temporär unterbinden und später jederzeit wieder aktivieren.
Aus Sicht eines Systemadministrators - also aus unserer Sicht - können wir noch ergänzen, dass es im Gegensatz zu Cron ohne ein setuid-Programm wie crontab auskommt und dass es keinen zentralen Daemon benötigt. Zurecht fragt der Autor nach dem Sinn von Konfigurationsdateien wie /etc/cron.allow, wenn doch ein zeitgesteuerter Job eigentlich nicht mehr ist als …