Ich bin jetzt mehrfach über die Tatsache gestolpert, dass nach dem Logout Prozesse wie hplip-gui hängen bleiben und so das ordnungsgemäße Schließen der Session verhindern.
Es gibt zwar keine graphische Oberfläche mehr, die Session ist lt. loginctl "closing", aber dort hängt sie dann.
Bisher hat mich das auch nicht wirklich gestört. Jetzt aber schon.
Folgendes Szenario:
Ich melde mich in Gnome an. Die Session wird erstellt, alles rennt, wie es soll. Ich melde mich ab.
Dann in der Arbeit melde ich mich per ssh daheim an. Also eine Text-Session. Ich baue ein Debian-Paket und verschlüssle es mit einem gpg-Key mittels aptly. Da werde ich zweimal nach dem Passwort für den Key gefragt. Die Abfrage schlägt fehl, weil der Dialog in ssh gar nicht erscheint.
Ich bin jetzt draufgekommen, dass dieser Dialog in der graphsichen Sitzung geöffnet wird. Da diese aber nicht mehr vorhanden ist - weil closing - schlägt die Abfrage sofort fehl.
Kille ich die graphische Sitzung im "closing"-State mittel
Code: Alles auswählen
loginctl kill-session 11
Auch gibt es Probleme, wenn ich mich mehrmals anmelde und abmelde (wie das ja üblich ist, wenn ein Rechner nicht jedesmal neu gebootet wird), dass irgendwann mal ein Login in gnome nicht mehr klappt. loginctl liefert dann einen ganzen Haufen Sessions im closing-State von Debian-gdm und meinem User... Kille ich sämtliche Sessions und starte gdm neu, ist der Login wieder möglich.
Jetzt gibt es mit systemd die Option (die seit 230 offenbar Standard ist), dass beim Logout Hintergrundprozesse gekillt werden. Es wird "aufgeräumt", wenn der letzte Login eines Users stattfindet. Damit sind dann tatsächlich die beschriebenen Probleme beseitigt.
Jedoch tut sich damit eine vieldiskutierte neue Baustelle auf.
Terminalmultiplexer, VNC-Server, X2Go-Server... die alle als User gestartet werden, werden mit dem letzten Logout auch beendet.
Die Diskussion ist die übliche. Pöttering ist schuld, die Welt wird einstürzen, systemd wird für den Hunger in der Welt und alle Kriege verantwortlich gemacht, und früher war sowieso alles besser. Darauf möchte ich jetzt gar nicht eingehen, weil es müssig ist.
Vielmehr möchte ich eine Lösung für diese Aufgabe finden, die "knackig" ist und das tut, was es soll.
Irgendwo in einer Diskussion im Fedora-Forum fand ich eine Erwähnung, dass man das doch über pam und eine neue session lösen könnte - Allerdings nicht weiter ausgeführt.
screen ist gegen pam gelinkt
Code: Alles auswählen
# ldd $(which screen)
linux-vdso.so.1 (0x00007ffcd06b0000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f78744ec000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f78742b4000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f78740a6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7873d08000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f7873ae0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f78738da000)
/lib64/ld-linux-x86-64.so.2 (0x000055edc97db000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f78736d4000)
Wenn ich mich lokal per ssh einlogge, wird eine neue session erstellt. loginctl zeigt das. Sowas müsste doch auch mit screen funktionieren?
Wie macht man sowas? Kennt sich damit jemand aus?
lg scientific