Bullseye Problem beim Herunterfahren

[mcb]

Holla,

ich habe auf Bullseye upgegraded - läuft bis auf ein paar Kleinigkeiten auch gut.

Problem:

beim Herunterfahren / Neustarten bleibt die Kiste jedesmal hängen -

nach unmounted /run/usr/1000/gvfs kommt

A stop job is running user ... for UID 1000 (xxx / 2min)

Das tritt auf 2 Instalationen auf einmal UEFI einmal Biosmode.

Google brachte leider nur jahrealte Treffer mit systemed

Wie finde ich den Fehler - das nervt -

Danke schonmal !

[MSfree]

Welches Deskttop Environment verwendest du?

Ich habe hier nämlich ein ähnliches Problem mit LXDE. Wenn ich mich allerdings aus dem Desktop auslogge und dann vom Loginscreen runterfahre, geht es sehr schnell (das ist mein momentaner Würgaround).

[whisper]

Gerade gestern hatte ich das auch,
bei mir war vermutlich noch eine nicht mehr genutzte ssh session offen.
Generell hatte ich das nicht. Ich habe hier momentan 4 Rechner mit Bullseye, und aller werden ab- und zu gebootet.
man gvs, zeigt erschreckend viel Kandidaten

[mcb]

Welches Deskttop Environment verwendest du?

Ich habe hier nämlich ein ähnliches Problem mit LXDE. Wenn ich mich allerdings aus dem Desktop auslogge und dann vom Loginscreen runterfahre, geht es sehr schnell (das ist mein momentaner Würgaround).

Gnome - aber es tritt jetzt "immer" auf

- boot Konsole #3 z.B.
- fwupd hatt ich drauf und habe ich runtergeschmissen wg critical bugs bei bullseye - obwohl tritt ja auch bei Rechner Nr. 2 auf der läuft nichtmal im UEFI-Mode.

Wo sucht man den überhaupt nach dem Fehler ?

[willy4711]

Ich hab Xfce/Testing.
Meine Kiste bleibt zwar nicht hängen, jedoch habe ich seit einiger Zeit eine merkliche Verzögerung, bevor der Desktop
geschlossen wird, und der Shutdown /Logout beginnt.
Dies betrifft das Panel / Mein Conky und das Cairo-Dock, die dann einfach nicht geschlossen werden.
Ich mache alle diese Funktionen über das Whisker Menü
https://docs.xfce.org/_detail/panel-plu ... enu-plugin

Ich habe dann die xfce4-session-*** Befehle durch die entsprechenden systemctl *** - Befehle ersetzt.



Damit ist die Verzögerung weg. Allerdings nur, wenn man den entsprechenden Button direkt platziert (Häkchen).
Der xfsm-shutdown-helper (ich nehme an, dass der das Ausstiegsfenster produziert) scheint trotzdem
nach wie vor die alten Befehle zu nutzen.

[mcb]

Auch so - wie würge ich den Desktop ab - von der Konsole ?

Wenn mich nicht alles täuscht ist der Fehler "neu" - der war nicht die ganze Zeit vorhanden.

[Blue]

@mcb:

Wenn mich nicht alles täuscht ist der Fehler "neu" - der war nicht die ganze Zeit vorhanden.

So isses.

Ich vermute, es ist ein "normales" Phänomen bei Debian/Testing:
Irgendwann kommt nach einem Update/Upgrade ein Bug, welcher nach irgendeinem weiteren Update/Upgrade dann wieder behoben wird.
Meiner Erfahrung nach ist es besser, bis dahin nicht zu versuchen, am System selbst herumzuschrauben, um nichts zu verschlimmbessern.

Oder man verwendet Debian/Stable, bei dem solche Update/Upgrade-Bug-Phänomene fast nie auftauchen.

Auch so - wie würge ich den Desktop ab - von der Konsole ?

Für dieses aktuelle Shutdown-Problem scheint die einfachste Zwischenzeitlösung zu sein, sich Abzumelden und im GDM3-Display-Manager den Computer herunterzufahren. Das läuft dann ohne 2-minütiges Däumchendrehen...

[whisper]

Ich vermute, es ist ein "normales" Phänomen bei Debian/Testing:
Irgendwann kommt nach einem Update/Upgrade ein Bug, welcher nach irgendeinem weiteren Update/Upgrade dann wieder behoben wird.
Meiner Erfahrung nach ist es besser, bis dahin nicht zu versuchen, am System selbst herumzuschrauben, um nichts zu verschlimmbessern.

Stimme ich zu. Hatte bei Buster, als es noch Testing war, ein ähnliches Problem, ging um Standby, ok Workaround gebastelt, nach einiger Zeit wars dann behoben, aber durch meinen Workaround gar nicht aufgefallen und nicht zu 100% wieder zurück zunehmen. Eigene Doofheit, war ich nicht ausführlich genug in der Doku.
Seit dem musste ich immer den Powerknopf zu Standby auslösen drücken, der Deckel wurde ignoriert.
Also wenn es nicht zu sehr nervt mal ein paar Tage/Wochen aushalten, und Fehler melden.

[mcb]

Der Fehler nervt mich schon - aber solange der Rest funzt was solls ...

Habe nur Bedenken das durch den timeout beim Herunterfahren etwas am Dateisystem verdreht werden könnete.

"A stop job is running for User Manager for UID 1000" · Issue #12262 · systemd_systemd · GitHub:

https://github.com/systemd/systemd/issues/12262

Wo meldet man Fehler bei Debian ?

[OrangeJuice]

Den Fehler konnte ich vor paar Tagen das erste Mal feststellen. Also einfach mal unter /var/log/apt nachschaue, welche Pakete das waren. Ich würde abwarten, bei Testing kann so etwas mal passieren und auch etwas länger dauern bis dies behoben wird.

Ich hatte in letzter Zeit Probleme unter Testing mit dem Firefox ESR aus Sid. Der schmiert einfach so ab oder hat das komplette System eingefroren, obwohl keine Internetseite geöffnet wurde. Im Moment läuft ein 78.6.0esr RC direkt von Mozilla ziemlich ruhig.

[mcb]

Ich warte erstmal ab

Wenn ich mich in Gnome abmelde und dann in die Konsole wechsele und mit Strg-Alt-Enf neustarte geht es schnell <-> dannach trodelt das Bios

Warte ich zwei Minuten beim Runterfahren shutown 0 ist das Bios schnell ...

[Blue]

@mcb:

Wenn ich mich in Gnome abmelde und dann in die Konsole wechsele...

Warum denn dieses Vorgehen? Warum "Konsole"?
Ich nehme doch an, dass Du das 2 Minuten warten müssen abkürzen willst.
Dazu würde ich, wie oben schon beschrieben, nach dem Abmelden im Abmeldebildschirm (= Display-Manager gdm3) oben den Ausschalte-Button drücken.
Dann fährt die Kiste wie gewohnt schnell herunter.

Spaßig gemeint: Unter Umständen wirst Du bei Bullseye im Testing-Modus auch noch andere kleine Stolpersteinchen erleben, bis es "Stable" ist.

[willy4711]

Drück mal ALT+F2
und gebe in das Fenster ein

Code: Alles auswählen

systemctl poweroff

was passiert dann ?

[OrangeJuice]

Drück mal ALT+F2
und gebe in das Fenster ein

Code: Alles auswählen

systemctl poweroff

was passiert dann ?

Klappt bei mir einwandfrei und der PC fährt schnell herunter.

[willy4711]

Ich hatte in letzter Zeit Probleme unter Testing mit dem Firefox ESR aus Sid. Der schmiert einfach so ab oder hat das komplette System eingefroren, obwohl keine Internetseite geöffnet wurde. Im Moment läuft ein 78.6.0esr RC direkt von Mozilla ziemlich ruhig.

Interessant
Hatte bei mir folgende beliebig reproduzierbare Erscheinung:

• VM läuft mit einem Host-Only Netzwerkadapter
  Ich starte FF (84.0 von Mozilla) ---> Batsch, System steht (keine Reaktion Tastatur / Maus).

Anders herum:
FF läuft ----> VM wird hochgefahren ---> Alles ok

Da ich keine Lust hatte, jedes mal den Power Knopf zu drücken, hab ich dann über eine Konsole die VM gekillt, und gut
war es.
Bin jetzt wieder auf NAT gewechselt, da ich Host only eh bloß brauchte, um mal was zu drucken.

[mcb]

Drück mal ALT+F2
und gebe in das Fenster ein

Code: Alles auswählen

systemctl poweroff

was passiert dann ?

Klappt bei mir einwandfrei und der PC fährt schnell herunter.

Heute kamen neue Updates - das Problem ist weg

systemctl ging vorher auch nur mit 2 min Wartezeit - jetzt funzt es natürlich! -