90 Sekunden stop job beim Shutdown. Warum? Was?

[karlmistelberger]

But (in case this helps):

me@ryzen:~> sudo systemctl status session-2.scope   
● session-2.scope - Session 2 of User me 
     Loaded: loaded (/run/systemd/transient/session-2.scope; transient) 
  Transient: yes 
     Active: active (running) since Tue 2022-01-18 17:37:33 CET; 4h 6min ago 
      Tasks: 128 
        CPU: 48.967s 
     CGroup: /user.slice/user-1000.slice/session-2.scope 
             ├─5042 /usr/libexec/sddm/sddm-helper --socket /tmp/sddm-auth8d4488b6-4b19-4537-83c8-1f2541462c8a --id 1 --start /usr/bin/startplasma-x11 --user me 
             ├─5053 /usr/bin/startplasma-x11 
             ├─5132 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display /usr/libexec/xinit/xinitrc 
             ├─5133 /usr/bin/gpg-agent --sh --daemon --keep-display /usr/libexec/xinit/xinitrc 
             ├─5188 /usr/lib64/libexec/kf5/start_kdeinit 
             ├─5189 "kdeinit5: Running..." "" "" "" "" "" "" "" "" "" "" 
             ├─5190 /usr/lib64/libexec/kf5/klauncher --fd=9 
             ├─5203 /usr/bin/kded5 
             ├─5207 /usr/bin/kwin_x11 
             ├─5218 /usr/bin/xsettingsd 
             ├─5287 /usr/bin/ksmserver 
             ├─5297 /usr/lib64/libexec/polkit-kde-authentication-agent-1 
             ├─5299 /usr/lib64/libexec/org_kde_powerdevil 
             ├─5301 /usr/bin/kaccess 
             ├─5303 /usr/bin/plasmashell 
             ├─5306 /usr/bin/xembedsniproxy 
             ├─5308 /usr/lib64/libexec/baloo_file 
             ├─5405 /usr/bin/gmenudbusmenuproxy 
             ├─5451 /usr/libexec/geoclue-2.0/demos/agent 
             ├─5580 scdaemon --multi-server 
             ├─6234 /usr/lib64/libexec/kf5/kioslave5 /usr/lib64/qt5/plugins/kf5/kio/kio_file.so file "" local:/run/user/1000/kded5RVloyA.1.slave-socket 
             └─6236 /usr/lib64/libexec/kf5/kioslave5 /usr/lib64/qt5/plugins/kf5/kio/kio_file.so file "" local:/run/user/1000/kded5LTsJGn.2.slave-socket 

Jan 18 17:48:54 ryzen kscreenlocker_greet[7336]: qt.svg: <input>:303:1453: Could not add child element to parent element because the types are incorrect.
Jan 18 17:48:54 ryzen kscreenlocker_greet[7336]: qt.svg: <input>:303:1631: Could not add child element to parent element because the types are incorrect.
Jan 18 17:48:54 ryzen kscreenlocker_greet[7336]: qt.svg: <input>:303:1739: Could not add child element to parent element because the types are incorrect.
Jan 18 17:48:54 ryzen kscreenlocker_greet[7336]: qt.svg: <input>:303:1980: Could not add child element to parent element because the types are incorrect.
Jan 18 17:48:54 ryzen kscreenlocker_greet[7336]: qt.svg: <input>:303:2223: Could not add child element to parent element because the types are incorrect.
Jan 18 17:48:54 ryzen kscreenlocker_greet[7336]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:47:9: Unable to assign [undefined] to bool
Jan 18 18:35:55 ryzen plasmashell[5303]: libkcups: Renew-Subscription last error: 0 successful-ok
Jan 18 19:34:15 ryzen plasmashell[5303]: libkcups: Renew-Subscription last error: 0 successful-ok
Jan 18 20:32:35 ryzen plasmashell[5303]: libkcups: Renew-Subscription last error: 0 successful-ok
Jan 18 21:30:55 ryzen plasmashell[5303]: libkcups: Renew-Subscription last error: 0 successful-ok

Since there was some complaint about "session-2.scope"...

Ja. Diese Ausgabe hilft weiter. Weitere Details gibt es mit pstree:

erlangen:~ # pstree -pt 1188 
sddm-helper(1188)───startplasma-x11(1200)─┬─gpg-agent(1288)─┬─scdaemon(13096)───{pipe-connection}(13098) 
                                          │                 └─{gpg-agent}(13099) 
                                          ├─ssh-agent(1287) 
                                          └─{QDBusConnection}(1296) 
erlangen:~ #

Verdächtig sind die fett markierten Prozesse, letztlich deren Vater gpg-agent(1288). Warum die bei dir Probleme machen und bei mir keine weiß ich leider nicht.

Vieelicht liegt es an einem der Konfigurationsfiles:

karl@erlangen:~> find -name '*gpg*' 
./.gnupg/S.gpg-agent 
./.gnupg/gpg.conf 
./.gnupg/pubring.gpg 
./.gnupg/pubring.gpg~ 
./.gnupg/trustdb.gpg 
karl@erlangen:~> 

[wodenhof]

Super, was man "nebenher" so lernen kann, danke für "pstree". Also

me@ryzen:~> find -name '*gpg*' 
./.gnupg/trustdb.gpg 
./.gnupg/gpg-agent.conf

gnupg/trustdb.gpg ist nur maschinenlesbar.

gpg-agent.conf:

default-cache-ttl 300
max-cache-ttl 999999

Gibt das Probleme?

Im Übrigen habe ich session-2.scope mal vor dem 'runterfahren per systemctl gestoppt. Das beendet die grafische Sitzung, die 90 Sekunden Wartezeit bleibt aber.

Das Einzige möglicherweise gpg-relevante was ich gemacht habe, ist das Kopieren von KWalletinhalten und dem Salt auf den neuen Rechner. Kann es das sein?

<edit> Eben habe ich den gpg-agent mit "kill -9 ..." beendet. Damit verschwindet die Menu-Leiste von KDE aber sonst passiert >2 Minuten nix. Ich musste von einer Konsole aus rebooten -- und durfte dann die obligaten 90 Sekunden warten. </edit>

[karlmistelberger]

Super, was man "nebenher" so lernen kann, danke für "pstree". Also

me@ryzen:~> find -name '*gpg*' 
./.gnupg/trustdb.gpg 
./.gnupg/gpg-agent.conf

gnupg/trustdb.gpg ist nur maschinenlesbar.

gpg-agent.conf:

default-cache-ttl 300
max-cache-ttl 999999

Gibt das Probleme?

Ich denke das kann schon sein. Ich habe kein gpg-agent.conf und habe mein .gnupg/S.gpg-agent gelöscht. Nach dem Ausloggen und erneutem Einloggen gibt es auch keinen scdaemon mehr (ein paar Stunden später war er wieder da).

Im Übrigen habe ich session-2.scope mal vor dem 'runterfahren per systemctl gestoppt. Das beendet die grafische Sitzung, die 90 Sekunden Wartezeit bleibt aber. Das Einzige möglicherweise gpg-relevante was ich gemacht habe, ist das Kopieren von KWalletinhalten und dem Salt auf den neuen Rechner. Kann es das sein?

Kann ich mir denken.

<edit> Eben habe ich den gpg-agent mit "kill -9 ..." beendet. Damit verschwindet die Menu-Leiste von KDE aber sonst passiert >2 Minuten nix. Ich musste von einer Konsole aus rebooten -- und durfte dann die obligaten 90 Sekunden warten. </edit>

Dieses Verhalten erwarte ich. Ich würde scdaemon und eventuell Söhne killen, überprüfen ob sie tatsächlich tot sind und dann rebooten.

Mein user karl ist schon fünf Jahre alt. Alte Files machen hin wieder Schwierigkeiten. Ich lösche sie meist ohne Folgen. Im Zweifelsfall habe ich einen Backup.

[wodenhof]

Tja, meine Versuche brachten mich irgendwie nicht weiter. Zunächst war gpg-agent.conf (umbenannt per "mv") nach dem nächsten Boot wieder da. Dafür lies sich scdaemon mit "kill -9 ..." nicht stoppen (automatischer sofort-restart mit neuer ID-Nummer). gpg-agent interessiert das kill-Kommando gar nicht, der bleibt einfach am Laufen. Kurzzeitig war session-2.scope.service dafür im Status (aktive, abandonned) -- warum auch immer. Nur das 'runterfahren bleibt bei 90 Sekunden Bedenkzeit. Irgendwie doof ...

[wodenhof]

Ach ja, das Entfernen der files aus kwalletd/ hat auch nichts gebracht.

[karlmistelberger]

Ach ja, das Entfernen der files aus kwalletd/ hat auch nichts gebracht.

Probiere doch "rm -r /.gnupg/".

[wodenhof]

Probiere doch "rm -r /.gnupg/".

Hab' ich. Der will aber nicht, d.h. 90 Sekunden warten ist weiter Pflicht. Und .gnupg/ ist nach dem Reboot wieder da...

[karlmistelberger]

Hab' ich. Der will aber nicht, d.h. 90 Sekunden warten ist weiter Pflicht. Und .gnupg/ ist nach dem Reboot wieder da...

Zuerst KDE verlassen und bei tty1 einloggen!

[wodenhof]

Zuerst KDE verlassen und bei tty1 einloggen!

Erledigt. Jetzt ist die Wartezeit 120 Sekunden ... und .gnupg/ ist auch wieder da.

[karlmistelberger]

Erledigt. Jetzt ist die Wartezeit 120 Sekunden ... und .gnupg/ ist auch wieder da.

Da hilft nur weiter stöbern: https://wiki.ubuntuusers.de/GPG-Agent/ Irgendein Programm ruft bei dir gpg-agent auf.