Stop Job beim shutdown! Ursache suchen und beheben.

[KP97]

Ach Tom, Du immer mit Deinen Einwänden...
Ob ich mir den Zähler 90 Sek. lang anschaue oder nur 10 Sek. ändert doch rein gar nichts, es spart nur Nerven.
Daß etwas beim Herunterfahren klemmt, weiß ich dann auch nach 10 Sek., denn sonst käme der Stopjob gar nicht erst zur Anzeige.

@Xantorix
Natürlich passiert da nichts, sonst hätte ich darauf hingewiesen.

[TomL]

Ach Tom, Du immer mit Deinen Einwänden...

Ich weiss... aber nur deshalb, weil ich mich selber gut kenne.... und weil ich weiss, wie schnell ich mich selber daran gewöhne, einen Fehler, der nicht mehr nervt, einfach aus Bequemlichkeit zu ignorieren.

[DEBIANUNDANDREAS]

von KP97 » 30.01.2018 19:43:16
Danke dein Tipp hat mir unter Ubuntu 16.04.3 geholfen.

[jkoerner]

Ich verwende die 10 Sekunden-Begrenzung bereits seit Wochen ohne negative Auswirkungen, bislang jedenfalls. Mir ist es wichtig nicht vor dem Monitor zu hocken und die Sekunden — das Ganze passiert ja ohne erläuternde Meldungen während des Vorgangs — herunterzuzählen. Ich mach' mich nicht zum Büttel meiner Technik.
Übrigens habe ich keine selbst erstellten Pakete installiert und nach einem Update war da plötzlich diese „a stop job is running for...“-Meldung.

[TomL]

Ich mach' mich nicht zum Büttel meiner Technik.

Man muss sich nur darüber im Klaren sein, dass damit das Problem nicht gelöst, sondern nur verdeckt wird. Das für mich fatale daran ist, dass sich diese Einstellung global auswirkt, obwohl nur eine einzige Anwendung Probleme verursacht. Und als sachliche Erklärung, warum man das so machen soll und gleichzeitig dabei vorgibt, eine pauschale Lösung für solche Probleme zu sein, erscheint mir diese obige Begründung einigermaßen bedenklich. So im Sinne von "Mein Auto macht vorne so komische Geräusche, aber seit dem ich das Radio laut stelle, ist das weg."

Ich denke auch, dass das speziell hier in diesem Fall unkritisch ist. Aber damit ist nicht ausgeschlossen, dass dieses Vorgehen an anderer Stelle massive Probleme verursachen könnte, wenn z.B. auf Grund eines Customizingfehlers eine App über den sigterm hinaus Sensor-Daten in eine DB speichern will und man killt sie mitten im Schreibvorgang. Kann das Auswirkung auf die Integrität der DB haben? Keine Ahnung... und ja, ich weiss, darum gehts hier nicht, aber der Threadbetreff sagt nix über die Art des Programmes aus... obs systemisch was wichtiges oder eher unwichtiges ist. Und jeder kann das kritiklos übernehmen. Klar, man kann das machen, ich halte das aber für eine schlechte Lösung.

[jkoerner]

Ob mein Auto vorn komische Geräusche macht oder mein PC — Ich habe nur einen PC im eigentlichen Sinne und bin nicht Betreuer für mehr als einen Rechner — ist meine persönliche Sache. Genau wie die Zeit die ich bereit bin für so etwas zu verplempern.
Vor 10 Jahren war das die Herausforderung die es zu lösen galt. Jetzt nicht mehr...
Solange die Kiste läuft ist's in Ordnung, sonst muß ich 'ne Lösung finden.
Meine Kiste kommt immer mit der ungefähren Meldung „cgroup2... nsdelegate...no such <"Dingsdabumsda">“ hoch und läuft trotzdem. Ist mir wirklich egal geworden. Kann aber jeder halten wie er will mit seinen PC-Meldungen. Da bin ich wirklich tolerant
[OT]Apropos: Ich habe auch Pickel am Hintern und renne damit nicht zum Hautarzt, oder sollte ich das? [/OT]

[NAB]

Wie schaut's denn aus, wenn ich noch schnell Daten auf den USB-Stick kopiere, was ja augenscheinlich sehr schnell gehen kann, aber im Hintergrund werkelt sync noch ewig. Wenn ich die Kiste dann herunterfahre ... killt Systemd mir dann auch meine Daten?

(Bei kaputten HDDs tut's das nicht. Da wartet es geduldig stundenlang, bis jeder einzelne Datenblock einen Timeout hatte)

P.S.: Im Tabos-Forum tut sich was:
https://www.tabos.org/topic/roger-fastp ... rfahren-2/
Der Fehler ist für Mint bestätigt, Ursache unbekannt.

[TomL]

[OT]Apropos: Ich habe auch Pickel am Hintern und renne damit nicht zum Hautarzt, oder sollte ich das? [/OT]

Das ist Deine Sache... nur der Rat für andere, das ebenfalls zu ignorieren, halte ich für geradezu verantwortungslos... denn beim nächsten könnte der Pickel ein Malignes Melanom sein... wobei Du dann im Anschluss ganz bestimmt kein einziges Wort darüber verlieren würdest, dass Dein Rat quasi ein finaler Rat war...

Für mich gibts nur eine Richtung für seriöse Ratschläge: Fehler identifizieren und beseitigen, aber garantiert nicht verdecken.... selbst dann nicht, wenn das in diesem Fall unkritisch wäre.

[Xantorix]

Code: Alles auswählen

nano /etc/systemd/system/before-shutdown.service

Code: Alles auswählen

[Unit]
Description=thlu:before-shutdown.service: Start at shutdown, reboot, halt
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "pkill roger"

[Install]
RequiredBy=shutdown.target reboot.target halt.target

Rechte setzen: root:root, 644

Code: Alles auswählen

systemctl enable before-shutdown.service

Hi, ich hab das mal probiert. Damit fährt mein PC gar nicht mehr herunter.

Xante

[scientific]

Ein Grund, warum ich diesen neuen Paketformen (ich nenns mal so) wie docker, flatpack und wie dieses Containerzeugs das alles für alle mitbringt, skeptisch gegenüber stehe, ist die tatsache, dass das für igend eine Distribution gebaut wird, die irgend ein Init-System hat und am eigenen Initsystem vorbei behandelt wird.
Und schon ists mit der Problemlosigkeit vorbei, welche diese Formate versprechen.

Hab ich das jetzt richtig verstanden, roger beendet sich nicht. Deshalb kann flatpack nicht beendet werden, und deswegen hängt systemd beim runterfahren des systems.

Ich hab leider/zum Glück noch keine Erfahrungen mit Flatpack... aber kannst du den Startaufruf nicht in eine systemd-Unit verpacken?
Und nicht nur ExecStart= sondern auch ExecStop= mit angeben, wo du den korrekten Befehl zum Beenden eines mit flat gestarteten Services reinpackst?

lg scientific

[TomL]

Damit fährt mein PC gar nicht mehr herunter.

*hmmm*... ... das ist denkbar, wegen des requires-Statements in der Unit und eines vielleicht fehlenden Exit-Codes 0 (bei Erfolg) aus "pkill", wenn möglicherweise "/bin/sh" wegen "nicht gefunden" mit 1 zurückkommt.

Ändere mal diese Zeile

Code: Alles auswählen

ExecStart=/bin/sh -c "pkill roger"

wie folgt ab:

Code: Alles auswählen

ExecStart=/bin/sh -c "/usr/bin/pkill roger"

Aber bitte vorher mal eben im Terminal kontrollieren, ob der Pfad wirklich so heisst:

Code: Alles auswählen

which pkill

Und nach der Änderung einmal die Änderung 'aktivieren' mit:

Code: Alles auswählen

systemctl daemon-reload

[NAB]

Hab ich das jetzt richtig verstanden, roger beendet sich nicht. Deshalb kann flatpack nicht beendet werden, und deswegen hängt systemd beim runterfahren des systems.

Ganz so ist es nicht ... ich zitiere da mal den Herrn Brummer aus dem Tabos-Forum:

Das Problem habe ich mit Linux Mint auch bei allen anderen Flatpaks gesehen, daher ist dies kein Roger Router Problem. Mint bzw Mate muss hier noch etwas nachbessern.

Mint versaut da also was Grundlegendes beim Umgang mit Flatpaks. Alle anderen (getesteten) Distributionen scheinen nicht betroffen zu sein.