[Eisfair] timer (was: leafnode pollt nicht mehr)

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

> Daher bin ich auch erst mal zufrieden das ich mir diese unterschiede
> bisher noch nicht an sehen muß. Cron reicht mir.

Die Syntax für die Beschreibung der Ausführungszeit(en) ist gänzlich anders.

Im Vergleich stellt man dann auch fest, dass es in beiden Spezielfälle gibt, 
die man so nur in einer der beiden Varianten definiert werden kann.

Für den Normalfall taugen beide gleichermaßen, speziellere Dinge gehen dann 
eher mal mit dem einen oder anderen, wobei mir systemd-Timer eventuell doch 
flexibler sein könnten.

cron hat z. B. den Vorteil, dass man sich mit

fcrondyn -x ls

eine Liste aller cronjobs anzeigen lassen kann; für systemd kenne ich einen 
solchen Befehl nicht.
 
>> Beim cron-Paket wird aus der cron-Konfiguration und den von diversen
>> Paketen angelegten cron-Vorlage "eine" Crontab erzeugt.
>> 
>> Bei systemd-timern ist ja jeder Job als eigene Datei im systemd-
>> Verzeichnisbaum anzulegen.
> 
> Und in wie fern ist das anders als einzelne crontab-dateien der Dienste
> oder des Systems zusammen zu setzen zu einer system crontab?

cron:

Aus den in der Cron-Konfiguration und den Vorlagen aus /var/spool/cron/... 
wird eine neue crontab-Datei geschrieben, womit durch das Überschreiben ja 
automatisch alle "veralteten", also nicht mehr konfigurierten Jobs, gelöscht 
werden.

>> Nimmt nun jemand in einer systemd-timer-Konfiguration einen Job raus
>> (löschen), sieht das nach Konfigurationsende automatisch startende
>> Konfigurationsscript ja nicht, welche Jobs nun nicht mehr gewollt sind.
> 
> Da verstehe ich nicht welcher Teil da nach konfig-ende was nicht mehr
> sieht. Wenn der timer-job eine datei ist und die gelöscht wurde dann
> sollte der timer wohl weg. Oder?

Nehmen wir mal an, du hättest zwei Jobs A und B in einer fiktiven systemd-
Timer-Konfiguration definiert.

Dann würden nach Abschluss des Konfigurationseditors für jeden der beiden 
Jobs je eine A.timer und eine B.timer im Dateisystem erzeugt.

Nun öffnest du erneut die systemd-Timer-Konfiguration und löscht darin den 
Job A. Nun wird nach Abschluss nur noch für für die Datei B.timer neu 
erzeugt. Wie soll das zuständige Skript den wissen, dass es den A.timer nun 
zu löschen hat?
 
Daher der angedachte Ansatz:

Welche Timer A, B,... sind vor Aufruf der Konfiguration vorhanden.
Konfoguration editieren, danach
Vergleich, welche der vorher "gesicherten" fehlt nun und muss nun gelöscht 
werden.

Es verbietet sich, dass das Konfigurationsscript einfach alle *.timer löscht 
und dann die in der Konfiguration festgelegten Timer neu erzeugt, denn damit 
würden auch systemd-Timer von Paketen oder manuell angelegte zerstört.

Übrigens verbietet sich die manuelle Manipulation an der crontab des cron-
Paketes, weil die eisfairintern immer neu geschrieben wird und damit eigene 
Änderungen somit verwirft, was du ja auch festgestellt hast.

-- 
Gruß Marcus
[eisfair-Team]