Cronjob @reboot

[Detlef Paschke]

Hallo,

ich brauche einen Cronjob, der nach dem Start bzw. nach dem Start + ein
paar Sekunden ausgeführt wird. Aussehen sollte das in etwa so:

@reboot sleep 10 && /usr/local/bin/...

Über die Konfiguration von Eisfair scheint das nicht vorgesehen zu sein.
Mit einem klassischen crontab -e öffnet sich die Cron Konfiguration aber
kann ich meine @reboot Zeile dort einfach so einfügen und bleibt sie
auch in Zukunft bestehen? Oder haben wir(Eisfair) dahingehend einen
anderen Ansatz?

Viele Grüße
Detlef Paschke

[Holger Bruenjes]

Hallo Detlef

Post by Detlef Paschke
ich brauche einen Cronjob, der nach dem Start bzw. nach dem Start + ein
@reboot sleep 10 && /usr/local/bin/...
Über die Konfiguration von Eisfair scheint das nicht vorgesehen zu sein.
Mit einem klassischen crontab -e öffnet sich die Cron Konfiguration aber
auch in Zukunft bestehen? Oder haben wir(Eisfair) dahingehend einen
anderen Ansatz?

ehmm, wieso ein cron Job fuer eine Aufgabe die nach dem Start
ausgefuert werden soll?



dafuer hilft sowas

/etc/systemd/system/deine_unit.service
------------------------
[Unit]
dein Name

[Service]
Type=oneshot
ExecStart=+Pfad zu deinem Skript
RemainAfterExit=yes
TimeoutStartSec=420

[Install]
WantedBy=multi-user.target
---------------------------

/usr/sbin/service enable deine_unit.service

Holger

[Detlef Paschke]

Post by Holger Bruenjes
Hallo Detlef

Hallo Holger,

Post by Holger Bruenjes

Post by Detlef Paschke
ich brauche einen Cronjob, der nach dem Start bzw. nach dem Start + ein
@reboot sleep 10 && /usr/local/bin/...

ehmm, wieso ein cron Job fuer eine Aufgabe die nach dem Start
ausgefuert werden soll?
dafuer hilft sowas
/etc/systemd/system/deine_unit.service
------------------------
[Unit]
dein Name
[Service]
Type=oneshot
ExecStart=+Pfad zu deinem Skript
RemainAfterExit=yes
TimeoutStartSec=420
[Install]
WantedBy=multi-user.target
---------------------------
/usr/sbin/service enable deine_unit.service

Dafür reicht auch ein Cronjob mit sowas:

@reboot sleep 10 && /usr/local/bin/script.sh

Post by Holger Bruenjes
Holger

Viele Grüße
Detlef Paschke

[Kay Martinen]

Post by Detlef Paschke
ich brauche einen Cronjob, der nach dem Start bzw. nach dem Start + ein
@reboot sleep 10 && /usr/local/bin/...
Über die Konfiguration von Eisfair scheint das nicht vorgesehen zu sein.
Mit einem klassischen crontab -e öffnet sich die Cron Konfiguration aber

Hast du es mal probiert?

Post by Detlef Paschke
auch in Zukunft bestehen? Oder haben wir(Eisfair) dahingehend einen
anderen Ansatz?

Das befürchte ich fast...

ehmm, wieso ein cron Job fuer eine Aufgabe die nach dem Start ausgefuert
werden soll?

Weil das der "Klassische Weg" wäre so was zu lösen, mit nur einer
verdammten Zeile text?

dafuer hilft sowas

Nach dem Motto "warum einfach wenn's auch Kompliziert geht"?

/etc/systemd/system/deine_unit.service
------------------------
[Unit]
dein Name
[Service]
Type=oneshot
ExecStart=+Pfad zu deinem Skript
RemainAfterExit=yes
TimeoutStartSec=420
[Install]
WantedBy=multi-user.target
---------------------------
/usr/sbin/service enable deine_unit.service

Also eine Unit die (eine andere Unit?) nur scharf schaltet und die dann
(wann?) ausgeführt werden sollte um das eigentlich erwünschte zu
erledigen???

Sorry aber da muß ich mal wieder lästern. Schön, ihr hab jetzt systemd
als schönes neues Spielzeug und das will/muß natürlich auch verwendet
werden. Aber ehrlich mal... geht's noch? Statt einem einzeiligen Aufruf
in der crontab mit dessen @reboot Marker sollen es jetzt zwei (?) units
sein mit jeder menge Text den man erst mal erfassen/finden soll?

Oder soll "deine_unit.service" hier nur eine sein, die sich nach dem
start selbst auf enable stellen sollte, was m.E. wohl hieße das sie erst
dann ausgeführt werden würde. Sprich: sie wäre vorher disabled und würde
NICHT ausgeführt, könnte sich demnach auch nicht enable'n und wäre damit
Sinnlos und Zeitverschwendung. Und als Konstrukt mehr eine
Selbsterfüllende Prophezeiung - die aber nie wahr werden würde?

ein einzelner @reboot eintrag macht m.E. genau das was er soll ohne das
ganze obige gewese.

Nochmal Sorry, aber ich kann es nicht ausstehen wenn einfache Lösungen
zugunsten maximaler Komplexität einfach nicht mehr möglich wären.

Das systemd keine Kenntnis von einem @reboot-zeitpunkt haben soll ist
ebenfalls schwer vorstellbar. Oder betrifft das nur die EISFAIR-Inkarnation?

Nebenbei ärgern mich beim Booten weiterhin Meldungen über dienste o.a.
die den Schirm voll müllen mit dem Kommentar das es für sie keine unit
gäbe und ein "generator" deswegen eine erstellen mußte. Mir ist es
eigentlich scheißegal wie die Dienste gestartet werden, sie sollen nur
laufen und beim booten wäre mir nur Übersichtlichkeit wichtig. Wie z.b.

[Eisfair SysV]
Dienst 1 ... [ok] läuft
Dienst 2 ... [ok] läuft

wobei man jeden Fehler schon am anderen Format (mit umbrechen) erkennen
konnte.

und nicht

[Eisfair systemd+generator]

Dienst 1 .... "ähh da muß ich erst mal eine Unit aus'm Arsch ziehen,
moment".... ja, ähh ... läuft.
Dienst 2 .... ähh da muß ich erst mal [u.s.w. bla bla bla] ... ... ...
... ... [nur um den üblen Textumbruch zu provozieren]
Dienst 3 ... hurra Unit gefunden... läuft.

U.s.w. So was ist zu begutachtung beim Booten untauglich.

Brauche ich jetzt einen 20" Monitor plus grub-setting, allein für
ordentlich lesbare bootmeldungen?

Kann man diese Geschwätzigkeit irgendwo abstellen? Denn offenbar ist das
umstellen aller dienste/Pakete auf mitgelieferte Units ein langzeit-plan.

:-( [Rant-Bombe geplatzt] Das mußte ich mal los werden.

Bye/
/Kay

[Rolf Bensch]

Hallo Detlef,

ich lege dafür in /var/cron/etc/root/ immer eine entsprechende Textdatei ab und starte den cron-Dienst neu. Das hat bisher alle Updates überlebt.

Grüße

Rolf

[Detlef Paschke]

Post by Rolf Bensch
Hallo Detlef,

Hallo Rolf,

Post by Rolf Bensch
ich lege dafür in /var/cron/etc/root/ immer eine entsprechende Textdatei ab und starte den cron-Dienst neu. Das hat bisher alle Updates überlebt.

stimmt, da war auch noch was, danke für den Tipp. Das werde ich mit

Post by Rolf Bensch
Grüße
Rolf

Viele Grüße
Detlef Paschke

[Marcus Röckrath]

Hallo Rolf,

Post by Rolf Bensch
ich lege dafür in /var/cron/etc/root/ immer eine entsprechende Textdatei
ab und starte den cron-Dienst neu. Das hat bisher alle Updates überlebt.

Wird es auch in Zukunft, solange du bei der Namenswahl keinen Dateinamen
wählst, der von anderen Paketen, also in der Regel keinen Paketdatennamen,
wählst.

Die Datei cron.base enthält die Jobs aus der Basiskonfiguration, mail die
des mail-Paketes, backup-zip.* vom backup-zip-Paket usw.

Es gibt keine Routine, die irgendwie das Verzeichnis "ausmistet".

[Rolf Bensch]

Hallo Marcus,

Post by Marcus Röckrath
Es gibt keine Routine, die irgendwie das Verzeichnis "ausmistet".

das ist prima so wie es ist!

Grüße

Rolf

[Detlef Paschke]

Am 06.04.2025 um 19:30 schrieb Marcus Röckrath:

Hallo Marcus,

Post by Marcus Röckrath

Post by Rolf Bensch
ich lege dafür in /var/cron/etc/root/ immer eine entsprechende Textdatei
ab und starte den cron-Dienst neu. Das hat bisher alle Updates überlebt.

Wird es auch in Zukunft, solange du bei der Namenswahl keinen Dateinamen
wählst, der von anderen Paketen, also in der Regel keinen Paketdatennamen,
wählst.
Die Datei cron.base enthält die Jobs aus der Basiskonfiguration, mail die
des mail-Paketes, backup-zip.* vom backup-zip-Paket usw.

ich danke dir, dann lege ich dort eine Datei mit der einen Cronzeile ab
und alles ist gut. Ist immer noch weniger aufwand, als für eine solche
Kleinigkeit mit Systemd Units herumzuspielen.

Es stellt sich natürlich die Frage, warum geläufige Variable @reboot in
base.exp nicht als Erlaubt aufgeführt ist? Es gibt ja noch etliche
weitere Variablen (@hourly, @weekly, @yearly...), die aber mit der
"normalen" Schreibweise (*/5 * * * *) umgesetzt werden können. Für
@reboot also das einmalige Ausführen nach dem start von Cron, wüste ich
keine andere Schreibweise.

Könnte man evtl. mal überdenken, diese Variablen in base.exp hinzuzufügen...

Viele Grüße
Detlef Paschke

[Detlef Paschke]

Post by Detlef Paschke
ich danke dir, dann lege ich dort eine Datei mit der einen Cronzeile ab
und alles ist gut. Ist immer noch weniger aufwand, als für eine solche
Kleinigkeit mit Systemd Units herumzuspielen.

Als Rückmeldung, eine Datei mit @reboot Cronzeile funktioniert unter
Eisfair ohne Probleme.

Viele Grüße
Detlef Paschke

[Detlef Paschke]

base.exp nicht als Erlaubt aufgeführt ist? ....
Könnte man evtl. mal überdenken, diese Variablen in base.exp hinzuzufügen...

Nur mal als Test habe ich in /etc/check.d/base.exp einfach und schnell
diese Änderung vorgenommen:

- CRONTAB = '([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)
*([0-7,/*(mon,tue,wed,thu,fri,sat,sun)-]+)'

+ CRONTAB = '([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)
*([0-7,/*(mon,tue,wed,thu,fri,sat,sun)-]+)|@reboot'

Man braucht keine Gruppen und nix, einfach als Alternation anfügen und
gut. Damit können (könnten) auch über die Konfiguration von Eisfair
@reboot Jobs definiert werden, die einmalig beim Systemstart ausgeführt
werden.

Viele Grüße
Detlef Paschke

[Marcus Röckrath]

Hallo Detlef,

Post by Detlef Paschke
+ CRONTAB = '([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)

Ich würde den ursprünglichen Teil Klammern, also eher sowas

(.......)|@reboot

[Detlef Paschke]

Post by Rolf Bensch
Hallo Detlef,

Hallo Marcus,

Post by Rolf Bensch

Post by Detlef Paschke
+ CRONTAB = '([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)

Ich würde den ursprünglichen Teil Klammern, also eher sowas

wäre die Frage, ob es nötig ist. Braucht man irgendwo die Gruppe für
einen Variablenaufruf? Funktionieren tut es mit und ohne Gruppe um die
klassische Schreibweise. Die Leute gruppieren und gruppieren und
gruppieren Ihre Reg Ausdrücke bis zum geht nicht mehr und man fragt
sich... Warum?
Aber die Klammer soll ja nicht das Thema sein.

Viele Grüße
Detlef Paschke

[Marcus Röckrath]

Hallo Detlef,

Post by Detlef Paschke

Post by Marcus Röckrath

Post by Detlef Paschke
+ CRONTAB = '([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)

Ich würde den ursprünglichen Teil Klammern, also eher sowas

wäre die Frage, ob es nötig ist. Braucht man irgendwo die Gruppe für
einen Variablenaufruf?

Nein, nicht weger der Gruppe:

"a b c|@reboot"

meint ja genaugenommen

a b c

oder

a b @reboot


Das @reboot wäre aber für den Crontab-Eintrag alleinstehend.

Genaugenommen müsste man

^((a b c)|d)$

damit nicht am Rand noch ziemlicher Blödsinn stehen kann.

Post by Detlef Paschke
Funktionieren tut es mit und ohne Gruppe um die
klassische Schreibweise.

Funktionieren tut es, kommt nur darauf an, wenn man irgendwelchen Blödsinn
noch mit reinschreibt, ob das dann auch noch durchgeht.

Die Checks macht man ja, um fehlerhafte Teile zu identifizieren.

Post by Detlef Paschke
Die Leute gruppieren und gruppieren und
gruppieren Ihre Reg Ausdrücke bis zum geht nicht mehr und man fragt
sich... Warum?

Ich teste und checke auch kieber zuviel als zuwenig.

[Detlef Paschke]

Post by Rolf Bensch
Hallo Detlef,

Hallo Marcus,

Post by Rolf Bensch

Post by Detlef Paschke

Post by Marcus Röckrath

Post by Detlef Paschke
+ CRONTAB = '([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)

Ich würde den ursprünglichen Teil Klammern, also eher sowas

wäre die Frage, ob es nötig ist. Braucht man irgendwo die Gruppe für
einen Variablenaufruf?

meint ja genaugenommen
a b c
oder

Das trifft aber in diesem Fall nicht zu, denn dann müsste letzte
Erfassung so aussehen. Die wäre natürlich nicht richtig.
Das ist es auch, so oder so:

(([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)
*([0-7,/*(mon,tue,wed,thu,fri,sat,sun)-]+))|@reboot

([0-9,/*-]+) *([0-9,/*-]+) *([0-9,/*-]+)
*([0-9,/*(jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec)-]+)
*([0-7,/*(mon,tue,wed,thu,fri,sat,sun)-]+)|@reboot

Aber wie gesagt, um die Gruppe ging es ja nicht sondern vielmehr darum,
dass es grundsätzlich kein größeres Problem sein sollte, die
standardmäßige Cron Variable @reboot in Eisfair aufzunehmen.

Viele Grüße
Detlef Paschke