Stop Job beim shutdown! Ursache suchen und beheben.

[Xantorix]

Hallo an alle Debianer,

ich habe beim Herunterfahren einen Stop Job. Leider komme ich nicht so recht weiter.
Wie kann ich am besten den Fehler finden und beheben.

Da das ganze nach dem Installieren einer Flatpak App auftrat habe ich bereits in den dortigen Foren nachgefragt.

Es handelt sich um Roger Router von Tabos. Leider komme ich dort nicht weiter.
Man sagte mir es müsste wohl mit systemd zusammen hängen.

Vielleicht kann mir jemand helfen.

Danke Xante

pastebin/?mode=view&s=40152

[rendegast]

Einen expliziten Fehler sehe ich nicht, "nur" das kommentarlose (vorzeitige) Ende bei Umountvorgängen.

Wie ist es nach Entfernen der App?

Ich sehe cgmanager, vermutet also wohl auch systemd-shim.

Wie ist es, wenn das System mit sysv gestartet wird?

Wie ist es mit "vollem" systemd?

Code: Alles auswählen

aptitude install  init systemd-sysv  systemd-shim_ cgmanager_

rsyslog 8.16.0 gibt es nur als jessie-backports arm-Platform und veraltetes sid hurd.

In jessie-backports wären systemd-Pakete Version 230 verfügbar. (halte ich für empfehlenswert)

Code: Alles auswählen

dpkg -l | egrep "215|systemd|udev"

[Xantorix]

Vielen Dank für die Antwort und die Anregungen.
Leider sind meine Kenntnisse hierbei sehr überschaubar und ich kann nicht so recht etwas damit anfangen.
Tut mir leid. Auch auf die Gefahr keine Hilfe mehr zu bekommen möchte ich mich outen, das ich einen Debian Ableger benutze.
Sorry ich habe mich vor einiger Zeit als Windows Umsteiger für Mint entschieden.
Nun laufen alle meine Maschinen Desktop auf Mint Mate produktiv.
Bisher konnte ich auch immer in den Mintforen Hilfe bekommen.

Die flatpak App zu entfernen ist nicht so einfach, da diese im Tagesgeschäft benötigt wird. Wenn ich die App manuell beende erfolgt der Shutdown wie gewohnt schnell ohne Stop Job.

Also wenn mir doch noch jemand helfen möchte, auch wenn ich Mint nutze und nicht so viel Ahnung habe, vielen Dank im Vor aus.

Gruß Xante

[TomL]

Also wenn mir doch noch jemand helfen möchte, auch wenn ich Mint nutze und nicht so viel Ahnung habe, vielen Dank im Vor aus.

Mir ist das eigentlich ziemlich egal, weil ich sowieso bei den Distros technisch immer viel mehr sehe, was gleich ist, als das, was wirklich unterschiedlich ist. Lediglich in den vertretenen Philosophien unterscheiden die sich doch ziemlich - was ich bei Mint allerdings einigermaßen als Zweifelhaft empfinde. Aber egal. Nur kann ich mit den gegebenen Infos nicht wirklich was anfangen. Ich habe mir gerade den Log-Auszug angesehen und habe nicht die leiseste Ahnung, was das -im Zusammenhang mit dem Problem- sein soll.... außerdem ist der Auszug ziemlich alt.

Ich denke, ein vollständiger Log-Auszug einer einzelnen normalen Von-Start-bis-Stop-Session, wo am Ende dieser Fehler auftaucht, könnte vielleicht aufschlussreicheres enthalten. Dazu muss erst mal kontrolliert werden, ob das Journal richtig eingestellt ist. Wie ist die Ausgabe von:

Code: Alles auswählen

cat /etc/systemd/journald.conf | grep -v '#'

Wenn

Code: Alles auswählen

journalctl -b -1

keine Ausgabe bringt, muss also erst Journald eingestellt werden. Und wenn es ein vollständiges Log der letzten PC-Einschaltzeit bringt, solltest Du einen aktuellen Auszug mal direkt nach dem Einschalten posten, wenn der Fehler beim vorherigen Ausschalten aufgetreten ist. Und den vorherigen Ausschalt-Vorgang nicht unterbrechen, sondern auch mit den Timeouts ohne Einwirkung zu Ende kommen lassen.

[Xantorix]

Vielen dank Thomas für deine Mühe. Das mit meiner Mintentscheidung ist leider im Moment nicht zu ändern. Zu der Zeit als ich von Windows weg bin schien es mir als für mich sinnvollste Lösung.

cat /etc/systemd/journald.conf | grep -v '#' gibt bei mir folgendes aus:
[Journal]
journalctl -b -1 gibt folgendes aus: Specifying boot ID has no effect, no persistent journal was found

Gruß Xante

[geier22]

Im Mint- Forum wurden dir Lösungen angeboten, die du ja ablehnst. Im Mint Forum hast du das Selbe Protokoll wie bei uns, aber ohne die Info

Ich hab mal mein syslog geleert und dann das System 11:51 Uhr gestartet, 11:57 heruntergefahren und 12:00Uhr wieder gestartet.

Na ja war auch so zu sehen.
rsyslogd gibt es bei Debian nicht hier gibt es nur rsyslog und das ist an sich auch überflüssig, es sei denn, man findet Gefallen daran, sich das Verzeichnis /var/log/ vollkritzeln zu lassen.
Deshalb:
Es sollte reichen, wenn du als root im Terminal mit

Code: Alles auswählen

# mkdir /var/log/journal

Das Verzeichnis für die Log- Dateien von Systemd anlegst.
Nach einem Neustart sollte dann Systemd dort seine Logs ablegen.
Die kannst du dann wie TomL gesagt hat abrufen.
Da der Network- Manager ja offensichtlich ein Problem hat - Ist zumindest die Letzte Meldung- (wahrscheinlich mit dem FlatPack) ist mir nicht klar, warum du bei Mint vorgeschlagene Lösung nicht benutzen willst.

Code: Alles auswählen

Jan  2 11:57:07 xante-I7 NetworkManager[962]: <warn>  [1514890627.6522] error requesting auth for org.freedesktop.NetworkManager.reload: Authorization check failed: Message recipient disconnected from message bus without replying
Jan  2 11:57:07 xante-I7 NetworkManager[962]: <warn>  [1514890627.6522] error requesting auth for org.freedesktop.NetworkManager.settings.modify.hostname: Authorization check failed: Message recipient disconnected from message bus without replying
Jan  2 11:57:07 xante-I7 rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="921" x-info="http://www.rsyslog.com"] exiting on signal 15.

[Xantorix]

Nochmals Danke. Die Lösung aus dem Mint Forum heist ja nur die Flatpak App zu beenden. Wenn auch per Script. Ich nutze die Lösung ja auch.
Auch einen Shutdown Starter habe ich erstellt. Leider ist mir die Lösung nicht sauber genug. Sorry.
Da ich gerne auch mal den Rechner am Power Button herunterfahren möchte oder auch mit dem STRG+Alt+Entf kann ich die Lösungen so auch nicht verwenden.

Ich habe bisher keine Möglichkeit gefunden für den Power Button ein shutdown script zu hinterlegen. Auch wenn ich nach Strg+Alt+Entf "Herunterfahren" bestätige schaffe ich es nicht dem shutdown Befehl die passenden Optionen mit zu geben.

Vielleicht meckere ich auch auf hohem Niveau. Aber der wahre Grund für den Stop Job wäre für mich interessant. Und natürlich dessen Beseitigung.

Nichts für ungut vielleicht habe ich etwas übersehen. Ich bin aber gerne bereit etwas zu lernen und nehme auch gerne Vorschläge an.

Gruß Xante

[TomL]

Im Mint- Forum wurden dir Lösungen angeboten, die du ja ablehnst. Im Mint Forum hast du das Selbe Protokoll wie bei uns, aber ohne die Info

Das ist aber nicht unbedingt ein Forum, wo die damit was anfangen können und sieht eher nach Rätselraten aus....
Ausserdem steht dort ja sogar der Problemverursacher .... CIFS .... in Verbindung mit "default wifi":

Code: Alles auswählen

Jan  2 11:51:23 xante-I7 NetworkManager[962]: <info>  [1514890283.3226] NetworkManager (version 1.2.6) is starting...
Jan  2 11:51:23 xante-I7 NetworkManager[962]: <info>  [1514890283.3227] Read config: /etc/NetworkManager/NetworkManager.conf (etc: default-wifi-

Also, das ist imho ein altbekannter Verursacher für Stopjobs und mit dem Trio NWM+WIFI+CIFS fast ein Standard-Problem. Ich würde einfach mal, um den Verdacht zu bestätigen, den folgenden Befehl vor dem Shutdown in einem Terminal-Fenster als root eingeben und dann erst den PC regulär runterfahren.

Code: Alles auswählen

umount $(grep "//" /proc/mounts | awk -F ' ' '{ print $1 }')

Damit sollte das Problem imho nicht auftreten. Wenns das war, kann man das einfach über eine Service-Unit einplanen, die vor dem Shutdown ausgführt wird.... Problem erledigt. Wenn dann jedoch der Dienst Probleme macht, der diese CIFS-Freigabe nutzt, dann setzt man den eben auf "conflicts shutdown.target" und dann sollte damit das Problem auch erledigt sein. Aber ich würds erst mal mit nem schlichten umount versuchen.

[Xantorix]

Ausserdem steht dort ja sogar der Problemverursacher .... CIFS .... in Verbindung mit "default wifi"

Hm, das ist ja interessant. Der betroffene Rechner nutzt kein WIFI.
Und das mit dem CIFS könnte tatsächlich eine Spur sein.

Die flatpak App ist Roger Router um über die Fritzbox zu faxen.

Mit Cifs wird der USB Stick der Box automatisch gemountet.

Deinen Vorschlag probiere ich später aus und melde mich. Momentan ist ein Herunterfahren nicht gut.

Gruß Xante

[TomL]

Ich würde vor dem Befehl prüfen, wie die aktiven mounts aussehen, und nach dem umounten noch mal prüfen, ob sie wirklich weg sind:

Code: Alles auswählen

df -h -T 

Und was auch geht und vielleicht sogar eine bessere Lösung wäre, einfach den blockierenden Service suchen und beenden:

Code: Alles auswählen

systemctl -l | grep roger -i

Wenn dann so eine Ausgabe kommt (oder ähnlich) wie:

Code: Alles auswählen

roger.service

kann man den Dienst einfach mit

Code: Alles auswählen

systemctl stop roger.service

beenden. Wobei jetzt allerdings unklar ist, ob dieser Dienst überhaupt selber den Mount durchführt und hinterher beendet oder ob er nur vorgefertigtes verwendet. Aber das kann man ja prüfen. Wieder vorher und nachher wie oben mit "df". Wenn der Fritzbox-Mount nach dem Stop des Dienstes immer noch lebt, dann muss der eben extra geschlossen werden. Oder wird der FB-USB-Stick schon in der fstab gemountet...? ... dann wärs klar.....

Und warum sagt der NWM "default-conf wifi"?

[Xantorix]

So.
df -h -T

Code: Alles auswählen

Dateisystem                Typ      Größe Benutzt Verf. Verw% Eingehängt auf
udev                       devtmpfs  7,8G       0  7,8G    0% /dev
tmpfs                      tmpfs     1,6G    9,6M  1,6G    1% /run
/dev/sda1                  ext4       19G    8,5G  8,8G   50% /
tmpfs                      tmpfs     7,8G     34M  7,8G    1% /dev/shm
tmpfs                      tmpfs     5,0M    4,0K  5,0M    1% /run/lock
tmpfs                      tmpfs     7,8G       0  7,8G    0% /sys/fs/cgroup
/dev/sda3                  ext4      197G     98G   89G   53% /home
cgmfs                      tmpfs     100K       0  100K    0% /run/cgmanager/fs
/dev/sdb5                  fuseblk   1,9T   1022G  842G   55% /mnt/01CCBCFDA5B19C10
//192.168.1xx.1/fritz.nas/ cifs      4,0G    324M  3,7G    9% /mnt/fritzplatte
tmpfs                      tmpfs     1,6G     72K  1,6G    1% /run/user/1000

sudo umount $(grep "//" /proc/mounts | awk -F ' ' '{ print $1 }')

Code: Alles auswählen

umount: /mnt/fritzplatte: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)

Scheinbar bleibt der Fritbox Mount bestehen.

systemctl -l | grep roger -i ------ Da kommt keine Ausgabe.

Gruß Xante

[TomL]

sudo umount $(grep "//" /proc/mounts | awk -F ' ' '{ print $1 }')

Code: Alles auswählen

umount: /mnt/fritzplatte: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)

Scheinbar bleibt der Fritbox Mount bestehen.

Ja, weil noch ein Prozess (vermutlich roger) offene Verbindungen darauf hat, kann der Mount nicht getrennt werden. Und weil es sich mit roger (was ich gerade erst gelesen habe) um einen Prozess handelt, der sich nicht an systemd-Regeln hält, kann systemd diesen Prozess anscheinend nicht im Shutdown handhaben. Und weil deswegen weder der Prozess noch der Mount geschlossen werden kann, hängt es halt in dem stop-job. Also, es muss zuerst roger vorher beendet werden und dann den Mount trennen, wie oben beschrieben. Wie der kill geht, stand schon im anderen Thread. Du hast Dich für eine Flatpak-Installation entschieden... nun musst Du leider die Probleme lösen... oder damit leben.... aber lösbar ist das.

Wenn der pkill das Problem löst, würde ich dafür eine Unit erstellen, die das und dann den Umount beim Shutdown durchführt.

[Xantorix]

Super vielen Dank. Jetzt weis ich etwas genauer was geht und was nicht.

Leider gibt es für die Fritzbox nicht so viele Faxmöglichkeiten die Faxen aus dem Lan und über IP einigermaßen fehlerfrei hin bekommen. Ich war froh Tabos mit Roger zu finden.
Nun steigen die halt auf flatpak um.

Gut wie der kill geht weis ich. Wenn Roger vor dem shutdown beendet wird geht es gut.

Wie bekomme ich das mit der Unit hin, dass roger bei jedem shutdown zuerst beendet wird?

Danke Gruß Xante

[geier22]

cgmfs tmpfs 100K 0 100K 0% /run/cgmanager/fs

wäre auch einen Möglichkeit:
vielleicht mal hier nachschauen?
https://wiki.archlinux.org/index.php/cgroups:

cgmanager is deprecated and does not work with systemd 232

[Xantorix]

Und weil es sich mit roger (was ich gerade erst gelesen habe) um einen Prozess handelt, der sich nicht an systemd-Regeln hält, kann systemd diesen Prozess anscheinend nicht im Shutdown handhaben.

Kannst du mir sagen wo du das gelesen hast?

Gruß Xante

[Xantorix]

@geier22 Danke für deine Mühe das ist nett. Leider sind meine Englischkenntnisse nicht gut genug um dort was zu verstehen. Sorry ich weis. Linux und schlechtes Englisch geht gar nicht.
Nun ich habe beruflich andere Prioritäten und Qualifikationen.
Vielleicht besteht ja die Möglichkeit mir hier auf etwas einfachere Weise zu helfen?
Ich bin gerne bereit mitzuarbeiten, aber das Aneignen umfangreicher Englischkenntnisse kann ich momentan leider nicht.
Ich habe als Selbständiger wenig Zeit und Sprachen sind nicht meine Stärke. Zumal es sich auch jenseits der 50 nicht mehr ganz so leicht lernt.

Also ich bin schon mal dankbar das ich bis dahin gekommen bin. Villeicht geht es noch ein Stück weiter.

Gruß Xante

[TomL]

Kannst du mir sagen wo du das gelesen hast?

Du hast das selber geschrieben bzw. im Mint-Thread aus dem Tabos-Forum zitiert. Der Rest sind einfache Rückschlüsse. Es gibt keine Service-Unit, also scheint es auch kein von systemd überwachter Dienst zu sein. Das bedeutet aber nicht, dass es sich das Programm nicht dennoch in den Hintergrund wegforkt... kann sein, muss aber nicht, vielleicht ist es aber auch nur eine Vordergrund-Anwendung. Auf jeden Fall ist es ein aktiver Prozess, der anscheinened nicht auf Signale von Systemd hört oder sie ignoriert oder gar nicht erst Signale bekommt, der aber anscheinend einen zuvor geöffneten Mount zur Fritz-Box verwendet. Wenn man den Mount nicht schließen kann, weil er offene Verbindungen hat, muss man halt zuerst den Prozess schließen, der diese Verbindung hat und dann danach den Mount trennen. Dann klappt das auch mit dem Stop-Job.

Man könnte das vielleicht mit einem vollständtigen Protokoll sehen, wie ich das oben schon zu Anfang beschrieben habe. Wenn das mit dem Journal nicht geht, muss es eben erst eingestellt werden. Solange man aber nicht konkret nachsehen kann, ist alles andere nur stochern im Nebel.

[Xantorix]

Hallo hier mal ein Versuch eines Logs.
Es ist sehr lang. Ich hoffe ich hab alles richtig gemacht.

journalctl -b -1 Ausgabe: 40153


Gruß Xante

[TomL]

Code: Alles auswählen

Jan 29 17:56:19 xante-I7 systemd[1574]: Stopping flatpak-org.tabos.roger-1799.scope.

Jan 29 17:57:49 xante-I7 systemd[1574]: flatpak-org.tabos.roger-1799.scope: Stopping timed out. Killing.
Jan 29 17:57:49 xante-I7 systemd[1574]: Stopped flatpak-org.tabos.roger-1799.scope.
Jan 29 17:57:49 xante-I7 systemd[1574]: flatpak-org.tabos.roger-1799.scope: Unit entered failed state.

Vermutlich wird hier das Problem liegen. Systemd fordert den Prozess zur Beendigung auf, welcher auch immer das im einzelnen ist, das müsste man herausfinden, aber die Aufforderung wird ignoriert und nach 90 Sekunden entfernt systemd den Prozess mit einem Kill. Und die 90 Sekunden sieht mal halt als Stop-Job. Wenn systemd das eh tut, kann man auch versuchen, selber zu killen, um eben den Stop-Job zu beseitigen. Der Fritzbox-Mount scheint nicht die Ursache zu sein, weils per Automount gemountet wurde. Man sieht im Log, dass der Mount ganz normal im Shutdownprozess umountet wurde.

[Xantorix]

Danke, ich hab den Ball mal zurück in das Tabos Forum gegeben.

Kann ich den kill für den Shutdown automatisieren? Und wenn ja wie.

Ich möchte das bei jedem shutdown zuerste ein pkill roger gemacht wird.

Gruß Xante

[NAB]

Es gibt keine Service-Unit, also scheint es auch kein von systemd überwachter Dienst zu sein.

Ich würde das hier für den von Systemd überwachten Dienst halten:

Code: Alles auswählen

systemd[1941]: Started flatpak-org.tabos.roger-2304.scope.

Nach meinem Verständnis wäre das Flatpak dafür zuständig, eventuelle Mounts überhaupt zu erlauben, ggf. auch durchzuführen und danach hinter sich aufzuräumen. Da scheint irgendwas schief zu laufen.

Der Herausgeber des Flatpaks kann Xantorix Problem aber nicht nachvollziehen und er wird an Systemd verwiesen:
https://www.tabos.org/topic/roger-fastp ... terfahren/
Aus mir nicht nachvollziehbaren Gründen scheint Herr Brummer dort aber der Meinung zu sein, dass das Flatpack kein (hängender?) Systemd-Job ist, ohne vorher ein Log gesehen zu haben.

Also entweder wäre wirklich Tabos der richtige Ansprechpartner, oder die Flatpak-Integration von Mint.

Xantorix, seit wann benutzt du das RogerRouter-Flatpak überhaupt? Dein Mint-Thread liest sich, als ob das Problem schlagartig mit 18.3 anfing und das RogerRouter-Flatpak vorher reibungslos lief?

[Xantorix]

Beides etwa zeitgleich. Genau kann ich das nicht mehr sagen leider.

[TomL]

Ich würde das hier für den von Systemd überwachten Dienst halten:

Du hast Recht, hab ich übersehen.

Nach meinem Verständnis wäre das Flatpak dafür zuständig, eventuelle Mounts überhaupt zu erlauben, ggf. auch durchzuführen und danach hinter sich aufzuräumen. Da scheint irgendwas schief zu laufen.

Das läuft über systemd-automount und ich denke, dass da kein Problem besteht.

Aus mir nicht nachvollziehbaren Gründen scheint Herr Brummer dort aber der Meinung zu sein, dass das Flatpack kein (hängender?) Systemd-Job ist, ohne vorher ein Log gesehen zu haben.

Wenn man aber nicht weiss, wie man das anzeigt, ist das aber auch nicht einfach. Xantorix kann ja jetzt den hier oberhalb von mir geposteten Snip verwenden, oder auch das ganze Pastebin... da geht ja imho draus hervor, dass dieser Job hängt.

Also entweder wäre wirklich Tabos der richtige Ansprechpartner, oder die Flatpak-Integration von Mint.

Darüber wird das natürlich nicht kurzfristig zu lösen sein. Aber man kann den Job auch kurzerhand selber via service-unit beim shutodwn entfernen. Allerdings müsste man vorher bestätigen, dass mit dem Kill der Fehler wirklich beseitigt ist. Ich persönlich habe allerdings die Meinung, dass flatpack keine gute Strategie ist.... aber egal... nun isses da.

[Xantorix]

Allerdings müsste man vorher bestätigen, dass mit dem Kill der Fehler wirklich beseitigt ist.

Wenn ich einen Starter mit 'sh -c "pkill roger; sleep 5; systemctl poweroff' erstelle fährt der PC ohne Stop Job herunter. Genau wie wenn ich Roger Router vor dem herunterfahren beende.

Was müsste ich für die entsprechende Unit tun?

Gruß Xante

[NAB]

Das läuft über systemd-automount und ich denke, dass da kein Problem besteht.

Wie könnte das funktionieren? Systemd kann doch nicht in das Flatpak reingucken ... und das Flatpak keine Automount-Unit erstellen?

Wenn man aber nicht weiss, wie man das anzeigt, ist das aber auch nicht einfach. Xantorix kann ja jetzt den hier oberhalb von mir geposteten Snip verwenden, oder auch das ganze Pastebin... da geht ja imho draus hervor, dass dieser Job hängt.

Richtig. Nur scheint Herr Brummer sein Flatpak als Ursache von vornherein auszuschließen. Entweder kann er hellsehen oder er weiß mehr als ich (was bei Flatpak keine Kunst wäre).

Ich persönlich habe allerdings die Meinung, dass flatpack keine gute Strategie ist.... aber egal... nun isses da.

Das sehe ich ähnlich ... aber dazu, ein eigenes Mint-Repository für die neusten RogerRouter-Versionen zu unterhalten, hat anscheinend auch keiner Bock ...

Xantorix, du könntest noch mal versuchen, das Flatpak per Hand zu starten und zu gucken, was es überhaupt macht. Ich wüsste zwar auch nicht, wonach man gucken sollte, aber nachher ist man ja manchmal schlauer. Die Syntax wäre:
flatpak run -v <Paketname>
Beenden mit Strg+C (das entspräche wohl dem, was Systemd macht) oder mit der Maus bzw. pkill (das entspräche dem, was reibungslos funktioniert). Gibt's da Unterschiede?