Hallo,

als "kleine" "Nebenwirkung" eines Softwareupdates, das ich gestern morgen gemacht habe, ist aus irgendeinem Grund von der Distribution der gute, alte dcron durch busybox cron ersetzt worden - was nicht unbedingt schön ist, aber an sich kein Problem wäre, so lange das Tool eben minütlich den Job startet, den es starten soll, der für die Verarbeitung der eingegangenen Sterne (sprich: Tophitberechnung) und der Sichtbarkeitsdaten zuständig ist.

Aber leider ist busybox cron auf die Nase gefallen, und das ohne irgendwo eine Meldung zu hinterlassen.

root@forum ~ # rc-service crond status
 * status: crashed
root@forum ~ # rc-service crond restart
 * Stopping busybox crond ...
 * start-stop-daemon: no matching processes found                                                                                                                               [ ok ]
 * Starting busybox crond ...                                                                                                                                                   [ ok ]
root@forum ~ # rc-service crond status
 * status: crashed

"no matching processes" ist normal, wenn man einen restart auf einen Dienst macht, der nicht läuft - das ist halt ein Hinweis darauf, das vorher etwas nicht in Ordnung oder gestartet worden war. Das letzte "ok" ist allerdings eine Lüge.
In den Logfiles findet sich auch nichts, na, fast nichts. rc-status schreibt dann auch ins Logfile "crashed", aber das hilft ja auch kein bisschen weiter.

Beim tieferen Nachsehen (sprich: Prozess tracen) fand ich dann das:

3770  setpgid(0, 0 <unfinished ...>
3770  <... setpgid resumed>)            = -1 EPERM (Operation not permitted)
3770  writev(2, [{iov_base="", iov_len=0}, {iov_base="setpgid", iov_len=7}], 2) = 7
3770  writev(2, [{iov_base="", iov_len=0}, {iov_base=":", iov_len=1}], 2) = 1
3770  writev(2, [{iov_base="", iov_len=0}, {iov_base=" ", iov_len=1}], 2 = 1
3770  writev(2, [{iov_base="", iov_len=0}, {iov_base="Operation not permitted", iov_len=23}], 2)           
= 23

setpgid(0,0) setzt die Prozessgruppe des Prozesses auf seine Prozess-ID. Das kann man so machen... aber dann sollte man auch damit klar kommen, was EPERM auch bedeuten kann: dass das schon so ist, weil der Aufrufer dafür gesorgt hat.
Aber wenigstens wird da eine Fehlermeldung ausgegeben, nur leider hat der Aufrufer (start-stop-daemon) stderr/out/in auf /dev/null umgelenkt, so dass die Fehlermeldung im Nichts landet. Alles was mir dazu einfällt, ist nicht druckreif.
Und eben der Aufrufer ist dann auch noch so [nicht druckreif], dass er den Exitcode irgendwo in seinem übertrieben komplizierten Code verliert.

Seufz. Aber wenigstens ist "ok" grün. Das ist sicherlich wichtiger als die Grundlagen mal richtig zu machen.

Ich habe jetzt noch 16 Container, in denen kein Cron läuft. Ich bin begeistert.

Gruß, Uwe

Ach Uwe, wenn wir Dich nicht hätten👍😊

An dieser Stelle liebe Grüße in den Maschinenraum, ohne den nichts läuft 👍😇

L.G Stefan

Hallo Stefan,

das Problem ist bekannt, wir werden es so schnell wie möglich beheben.

Viele Grüße

Wolfram

Die TOP 50 scheinen auch seitdem eingefroren zu sein.

Ja, ich gehe mal davon aus dass das zusammenhängt.

Dem Erstplatzierten sei es gegönnt😉👍

L.G Stefan

Danke Wolfram👍