[erledigt] openSUSE Leap 15.0: 'reboot' klappt nicht

  • Das Script ist Teil meiner RRD-Tool Scripte, mit denen ich verschiedene Sachen protokolliere. Es wird von einem übergeordneten Script (via crontab) alle 5 Minuten aufgerufen, und startet, wenn "$ETH.dat" länger nicht beschrieben wurde, einen Hintergrundprozess, der alle 30 Sekunden die aktuelle Anzahl der Bytes, die über die Schnittstelle gegangen sind, in die Datei schreibt (das ist nötig, weil ansonsten der Counter überlaufen könnte). Eine "Unit" für dieses Script ist also in keinster Weise sinnvoll ;-).

    Mir ist noch nicht ganz klar, welchen Zweck das haben soll das Skript nicht einfach als Daemon die Daten sammeln zu lassen - wenn es einmal nach dem Forken die Endlosschleife erreicht hat gibt es soweit ich das als Perl-Laie sehen kann keinen Mechanismus im Skript sich selbst wieder zu beenden - oder greifen deine Skripte da noch irgendwie ein?


    Das Auslesen der Daten aus der Datei könnte dann unabhängig vom Sammeln erfolgen und das wäre als periodisch auszuführende Aufgabe eher etwas für cron (bzw. einen Systemd-Timer :versteck) als ein von Cron gestartetes endlos laufendes Skript, das ohne definierte Abhängigkeiten zu anderen Diensten bzw. Mount-Units ausgeführt wird, obwohl es diese Abhängigkeiten eindeutig besitzt.

    Wobei Gentoo ja anscheinend auch bereits "infiziert" ist...

    Bei Gentoo ist so gut wie alles optional (systemd ist eines der use-flags), und systemd ist da nur eine von vielen Möglichkeiten für das Init-System, Standard ist soweit ich weiß immer noch OpenRC.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Bei Gentoo ist so gut wie alles optional (systemd ist eines der use-flags), und systemd ist da nur eine von vielen Möglichkeiten für das Init-System, Standard ist soweit ich weiß immer noch OpenRC.

    ist so.


    Wobei ich inzwischen alle meine gentoo-systeme auf systemd umstelle, weil es mir persönlich mehr Komfort, besserer logging und vor allem Startgeschwindigkeit bietet. Aber ja, es ist anders. Deutlich anders.


    Christian

  • Mein openSuse VDR startet, seit Suse auf systemd umgestellt hat, deutlich schneller.

    Das dadurch nötige Einarbeiten in systemd hat mich einiges an Nerven gekostet. Andererseits bietet systemd super Analysemöglichkeiten.

    Man muss sowieso dauernd dazu lernen ...


    Und wie seahawk1986 in #11 vorschlägt, ist das auch eine Chance alte Sachen "aufzuräumen".

    Am Ende ist es dann sauberer als vorher, denn systemd erzwingt mehr Genauigkeit.

  • @seahawk1986 Ich verwende für verschiedene Statistiken auf meinen Rechnern seit jeher ein Perl-Script, das alle 5 Minuten via cron aufgerufen wird. Dieses ruft seinerseits für jede Statistik ein Script auf, das die Daten liefert, und speichert diese mit RRDtool. Eines dieser Scripte liefert bei jedem Aufruf die während der letzten 5 Minuten übertragenen Bytes. Das können bei einer GBit-Schnittstelle mehr sein, als mit 32 Bit darstellbar ist. Daher startet dieses Script einen Hintergrundprozess, der die Daten alle 30 Sekunden abfragt und zwischenspeichert, so dass kein Überlauf passiert. Dass es hierfür einen separaten Prozess braucht ist etwas, das sich innerhalb dieses Scripts abspielt und nicht nach aussen dringt. Das übergeordnete Statistik-Script weiß davon nichts. Und so soll es auch bleiben. Systemd hat hier nichts verloren.


    Klaus

  • jrie Etwas OT, aber wie schnell ist "deutlich schneller" ?

    Ich verwende Gentoo/OpenRC, und da braucht VDR bis er alle Sachen beisammen hat (Tuner,CAM) für den Start gefühlt zumindest genau so lange wie der reine Bootvorgang dauert.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Das ist Jahre her, deswegen etwas vage geschätzt: weniger als die Hälfte. Jedenfalls so deutlich wahrnehmbar, dass man sich wundert und freut.

  • Dass es hierfür einen separaten Prozess braucht ist etwas, das sich innerhalb dieses Scripts abspielt und nicht nach aussen dringt. Das übergeordnete Statistik-Script weiß davon nichts. Und so soll es auch bleiben. Systemd hat hier nichts verloren.

    Das ganze Problem besteht ja, weil etwas nach außen dringt, denn über cron wird ein endlos laufender Prozess gestartet, der nicht vom Init-System kontrolliert wird und dessen Abhängigkeiten beim Herunterfahren nicht berücksichtigt werden. Und man hat nach einem Neustart bis zu 2 Aufrufe des Skripts, in denen kein neu angefallender Traffic geloggt werden kann, weil das Skript erst dann forkt (und damit die Datei mit neuen Werten beschreiben kann), wenn die mtime der Datei weit genug in der Vergangenheit liegt.


    Aber wenn man das Konstrukt aus den Perl-Skripten unverändert lassen will, könnte man statt cron eine Systemd-Unit nutzen, die die nötigen Abhängigkeiten besitzt, als KillMode=control-group hat und selbst ein Skript startet, das das Statistik-Skript alle 5 Minuten in einer Endlosschleife aufruft - dann werden alle Prozesse in der cgroup beim Herunterfahren rechtzeitig abgeräumt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • @seahawk1986 Es ist sehr nett, dass du dir so viele Gedanken machst. Aber das eigentliche Problem ist für mich ja gelöst (siehe #20).

    Mit systemd möchte ich so wenig wie möglich zu tun haben. Mein Statistik-Script läuft für mich vollkommen zufriedenstellend. Und ob ein Prozess, der endlos läuft vom Init-System kontrolliert wird oder nicht sollte beim Runterfahren keine Rolle spielen. Systemd kann ja gerne erstmal alle seine Abhängigkeiten abspulen, aber wenn am Schluß noch was übrig bleibt, dann soll er gefälligst, wie das seit jeher üblich war, SIGTERM und nach einem Timeout (von wenigen Sekunden) SIGKILL schicken. Wenn ich dem System sage "shutdown" bzw. "reboot", dann hat das stattzufinden, und nicht irgendwo hängenzubleiben,


    Klaus

  • Aber das eigentliche Problem ist für mich ja gelöst (siehe #20).

    Damit hast du aber nichts anderes gemacht als für die cron.service KillMode=control-group zu setzen (laut man systemd.kill ist das die Voreinstellung, wenn nichts anderes angegeben wird) und die Nebenwirkungen davon mochtest du in #19 nicht, wenn ich dich richtig verstanden habe.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hmm, da hast du recht. Da muss ich bei meinen Versuchen wohl etwas übersehen haben.

    Aber auch egal, so oft restartet man cron ja auch wieder nicht ;-).

    Für mich ist es so auf jeden Fall akzeptabel, denn das System fährt runter bzw. rebootet, wenn ich es von ihm verlange. Hauptsache, ich habe nichts mit systemd zu tun ;-).


    Klaus

  • Das hat mir jetzt doch keine Ruhe gelassen. Auf dem alten VDR unter openSUSE Leap 42.2 bricht ein Restart von cron tatsächlich mein Script *nicht* ab. Unter Leap 15.0 dagegen schon. Den Test von #20 hatte ich wohl unter 42.2 gemacht und erwartet, dass das auch unter 15.0 so funktionieren wird.


    Die Datei /etc/systemd/system/multi-user.target.wants/cron.service unterscheidet sich auf den beiden Rechnern nur in dieser Zeile:


    < After=nss-user-lookup.target network.target time-sync.target

    ---

    > After=ypbind.service nscd.service network.target


    wobei die erste von 15.0 und die zweite von 42.2 stammt.

    In beiden Fällen ist *kein* "KillMode=..." enthalten.

    Hat sich da zwischen systemd 228 und 234 der Defaultwert verändert?

    Oder kann man sich dabei nicht darauf verlassen, dass etwas, das heute funktioniert, morgen auch noch funktioniert? ;)


    Klaus

  • Hat sich da zwischen systemd 228 und 234 der Defaultwert verändert?

    Soweit ich das den Manpages aus der Zeit entnehmen kann (müsstest du auch auf dem jeweiligen System nachlesen können), hat sich da am von Upstream vorgegebenen Default-Wert nichts geändert. Da müsste man im Zweifelsfall das Quellpaket und die Konfigurationsdateien auseinander nehmen, ob da abweichende Default-Werte gesetzt wurden und wie es mit der cgroup-Unterstützung im verwendeten Kernel aussieht - bei Releases, die ihr EOL längst erreicht haben, ist das eher was für historisch interessierte - das Ziel ist ja eigentlich nur sich mit dem aktuell genutzten Release zu arrangieren, statt darüber zu sinnieren, dass früher alles besser war.

    Oder kann man sich dabei nicht darauf verlassen, dass etwas, das heute funktioniert, morgen auch noch funktioniert?

    Darauf kann man sich bei Software nicht unbedingt verlassen, wenn man Versionssprünge macht (Microsoft und Apple schaffen das regelmäßig sogar innerhalb einer Major-Version). Systemd ist wie jede andere Software auch nicht perfekt (aber hat sich in den letzten Jahren aber spürbar stabilisiert) und hat einen mitunter nicht ganz unkomplizierten Hauptentwickler - aber das ist ja fast schon Tradition bei vielen Projekten ...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!