Nach Ende der Sitzung (XFCE) hätte ich gern "umount"

[spiralnebelverdreher]

Hallo zusammen,
in einem Debian stable mit XFCE Oberfläche kann der Nutzer (mit Kenntnis des Root Passwortes) eine Partition einer internen Festplatte mounten (auf /media/username/uuid) . Nach Beenden dieser Sitzung bleibt das Gerät gemountet.
Das hätte ich gerne geändert: Sobald der Nutzer sich abmeldet sollen automatisch alle in der Sitzung gemounteten Geräte freigegeben werden. Wo ist die Stellschraube dafür?

Viele Grüße

sprialnebelverdreher

[bullgard]

Ich nehme an, daß Du anschließend eine neue Sitzung startest und erwartest, daß sich Dir dann der Rechner so präsentiert wie bei Beginn der ersten Sitzung.
Das wird aber bei

Sobald der Nutzer sich abmeldet sollen automatisch alle in der Sitzung gemounteten Geräte freigegeben werden.

nicht der Fall sein. Denk noch einmal nach, was Du genau erreichen möchtest.

[scientific]

Wie mountest du die fraglichen Partitionen? Ganz konkret.

[spiralnebelverdreher]

Wie mountest du die fraglichen Partitionen? Ganz konkret.

Ich mounte die Partition üblicherweise durch Anklicken im Thunar (linke Leiste). Die Partition ist nicht in der Datei /etc/fstab enthalten und wird (vermutlich von einem Helferlein à la udisks) gemountet auf /media/Username/UUID_der_Partition.

[spiralnebelverdreher]

Ich nehme an, daß Du anschließend eine neue Sitzung startest und erwartest, daß sich Dir dann der Rechner so präsentiert wie bei Beginn der ersten Sitzung.
Das wird aber bei

Sobald der Nutzer sich abmeldet sollen automatisch alle in der Sitzung gemounteten Geräte freigegeben werden.

nicht der Fall sein. Denk noch einmal nach, was Du genau erreichen möchtest.

Der Komfortmehrwert ist mir schon ersichtlich, und bei einem einzigen Nutzer ist das ja hilfreich. Aber bei mehreren Benutzern an einem Rechner kann es dann halt sein, dass Nutzer A eine Partition xyz mountet (absichtlich, oder weil er sich verklickt hat), am Ende alle Anwendungen (inkl. Thunar) schließt und sich abmeldet. Nutzer B meldet sich an und wundert sich, dass Partition xyz auf einen Pfad im Dateisystem gemounted ist, zu dem er keinen Zugang hat.
Ich hätte es halt gerne "einfacher": Nach dem Beenden der Sitzung alle Dateisysteme umounten, die in der Sitzung gemounted wurden. Im Thunar ist der optische Unterschied zwischen "Partition gemounted" und "Partition nicht gemounted" recht gering. Das übersieht man schnell.

[TomL]

Der Komfortmehrwert ist mir schon ersichtlich, und bei einem einzigen Nutzer ist das ja hilfreich. Aber bei mehreren Benutzern an einem Rechner kann es dann halt sein, dass ....

Ich habe genau dieses Problem gelöst.... also mehrere Benutzer können sich nacheinander auf einem System anmelden und bekommen ihre Server-Laufwerke passend gemountet. Melden sie sich ab, werden die Mounts getrennt. Darüber hinaus ist auch noch gelöst, dass bei mobilen Laptops passend darauf reagiert wird, ob das "richtige" Netz verbunden ist und ob der Server überhaupt erreichbar ist. Und als letztes ist sichergestellt, dass WLAN-Verbindungen bei diesen Geräten nicht vorher gekappt werden, bevor die Server-Laufwerke umountet sind. Darüber hinaus ist auch noch die Einbindung vom OpenVPN-Verbindungen zum Server unterstützt, so das man eben auch von irgendwo unterwegs seine Postfächer öffnen kann.

Aber das alles zusammengenommen ist nicht trivial und erfordert ein wenig Einarbeitung Aber es hat sich bei unseren stationären und reisenden Multiuser-Geräten als die perfekte und wartungsfreie Lösung erwiesen. Ich habe das auf meiner HP beschrieben. Wenns Dich interessiert, kann ich Dir nen Link senden. Selbst um nur Anregungen zu übernehmen ist es allemal tauglich.

[scientific]

Im Prinzip willst du die gvfs-mounts wieder aushängen...

Probiers mal mit

Code: Alles auswählen

 KillUserProcesses=true

in /etc/systemd/logind.conf.

Anschließend rebooten und testen.

Ich vermute, dass der Debian-Standard, der nicht der systemd-Standard ist, das verursachen könnte.

Lg scientific

[spiralnebelverdreher]

Im Prinzip willst du die gvfs-mounts wieder aushängen...
Probiers mal mit

Code: Alles auswählen

 KillUserProcesses=true

in /etc/systemd/logind.conf.

Ist das nicht ein bißchen mit dem Holzhammer zugehauen?

Meine Prozessliste nach dem Abmelden sah gestern so aus:

Code: Alles auswählen

spiral   819  0.0  0.0  65212  6812 ?        Ss   22:27   0:00 /lib/systemd/systemd --user
spiral   820  0.0  0.0  86888  1860 ?        S    22:27   0:00 (sd-pam)
spiral   836  0.0  0.0  45504  4332 ?        Ss   22:27   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
spiral   877  0.0  0.0 348668  5752 ?        Ssl  22:27   0:00 /usr/lib/at-spi2-core/at-spi-bus-launcher
spiral   882  0.0  0.0  45244  3972 ?        S    22:27   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
spiral   888  0.0  0.0  56672  5088 ?        S    22:27   0:00 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
spiral   894  0.0  0.0  91664  3228 ?        SLs  22:27   0:00 /usr/bin/gpg-agent --supervised
spiral   924  0.0  0.0 284552  6808 ?        Ssl  22:27   0:00 /usr/lib/gvfs/gvfsd
spiral   976  0.0  0.3 247704 31528 ?        Sl   22:27   0:00 /usr/bin/python3 /usr/share/system-config-printer/applet.py
spiral   997  0.0  0.0 187292  4940 ?        Sl   22:27   0:00 /usr/lib/dconf/dconf-service
spiral  1013  0.0  0.1 503312 12088 ?        Ssl  22:27   0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
spiral  1032  0.0  0.0 360732  7596 ?        Sl   22:27   0:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.16 /org/gtk/gvfs/exec_spaw/0
spiral  1037  0.0  0.0 193612  4720 ?        Ssl  22:27   0:00 /usr/lib/gvfs/gvfsd-metadata

Welcher von den Viechern ist denn der, der beim Abschießen den Mountpunkt wieder freigibt? 924 zusammen mit 1032? Auch 1037?

[scientific]

Lies mal die Diskussionen darüber.
Diese Prozesse brauchst du alle nach dem Abmelden nicht mehr. Im ungünstigen Fall blockieren sie sogar eine Wiederanmeldung.

Melde dich ein paar mal an und ab. Dann schau, mit

Code: Alles auswählen

 loginctl

wieviele Sessions vom User spiral noch offen sind. Die sind dann alle im State "closing" weil das Beenden nicht fertig wird. Unsauber programmierte Dienste verursachen das. Hp-systray ist einer von vielen.

Wenn du abgemeldet bist, sollte kein Programm mit deiner UID mehr laufen.

Solange du kein screen oder tmux verwendest, gibts auch keine Probleme. Ganz im Gegenteil. Gvfs wird auch beendet, und deine Usermounts wieder ausgehängt.

Falls du screen benutzen willst, hab ich auch eine Lösung für dich.

Lg scientific

[spiralnebelverdreher]

Lies mal die Diskussionen darüber.
Diese Prozesse brauchst du alle nach dem Abmelden nicht mehr. Im ungünstigen Fall blockieren sie sogar eine Wiederanmeldung.

Melde dich ein paar mal an und ab. Dann schau, mit

Code: Alles auswählen

 loginctl

wieviele Sessions vom User spiral noch offen sind. Die sind dann alle im State "closing" weil das Beenden nicht fertig wird. Unsauber programmierte Dienste verursachen das. Hp-systray ist einer von vielen.

Wenn du abgemeldet bist, sollte kein Programm mit deiner UID mehr laufen.

Solange du kein screen oder tmux verwendest, gibts auch keine Probleme. Ganz im Gegenteil. Gvfs wird auch beendet, und deine Usermounts wieder ausgehängt.

Falls du screen benutzen willst, hab ich auch eine Lösung für dich.

Lg scientific

Danke für dein Hilfe!
Screen oder tmux verwende ich derzeit nicht.

[scientific]

Kurze Frage:

Klappt es jetzt?

Nur zur Erklärung, warum die systemd-Standardeinstellung, alle Userprozesse beim Ausloggen zu killen die bessere gegenüber dem Debian-Standard ist.
Früher, so wird berichtet, hat der Sysadmin einmal in der Woche alle Prozesse, die keiner Session mehr zugeordnet werden konnten, manuell gekillt. Das dürfte über Jahrzehnte in Unix gängige Praxis gewesen sein. Daher hat es auch niemanden gestört.

Systemd bricht mit dieser Praxis, weil die Entwickler behaupten, dass dieses tradierte Verhalten eigentlich "falsch" ist. Wenn ich mich auslogge, hat kein Prozess mehr von mir übrigzubleiben.
Mir ist das aufgefallen, weil ich mich gelegentlich nicht mehr einloggen konnte, mit loginctl feststellte, dass 5, 10 oder mehr Sessions noch vorhanden waren. Bei genauerer Untersuchung stellte sich heraus, dass die alle "State; Closing" hatten.
hp-systray, zeitgeist-datahub, und noch einige andere Prozesse der Gnome-Session beendeten sich einfach nicht. Denn diese wurde per xdg-autostart zwar innerhalb des systemd-services user@1000.service gestartet, aber nicht mit der Gnome-Session beendet. Daher liefen die weiter und blockierten das ordnungsgemäße ausloggen und beenden von user@1000.service.
Ein Restart von gdm3 ließ mir mehrere Sessions von gdm übrig. Auch alle im State=Closing.

Bin dann auf die Suche gegangen und habe festgestellt, dass KillUserProcesses=false eingestellt ist. Hab die Diskussion der systemd-Entwickler mit angepissten Sysadmins gelesen und bin zum Schluß gekommen, dass systemd wieder einmal richtig liegt. Bin dann mit screen auf die Schnauze gefallen... aber das muss halt außerhalb einer user-Session gestartet werden, nämlich von PID 1. Hab mir eine entsprechende Unit gebaut, und jetzt klappt es wunderbar. Keine Hänger beim Login, keine Hänger beim Shutdown, keine gemounteten gvfs-Filesysteme nach dem Logout... usw.

Und wenn ich mich per ssh einlogge, starte ich

Code: Alles auswählen

screen -UxR

und verbinde mich mit der vorbereiteten Screen-Session. Kann Screen detatchen und daheim in meiner normalen Gnome-Session im Terminal oder am TTY screen wieder mit -UxR aufrufen und bin wieder mit dieser Session verbunden und arbeite weiter. Mit exit beende ich alle diese und screen restartet automatisch und ist wieder jungfräulich bereit.


lg scientific

[spiralnebelverdreher]

Kurze Frage:

Klappt es jetzt?
lg scientific

Die Prozesse werden beendet, aber der mount bleibt bestehen. Was auch nicht ganz verwunderlich ist, da der Nutzer ja das root Passwort eingeben muss und das Dateisystem nicht in der getan steht.

[scientific]

Das ist aber seltsam... Warum benötiigst du zum mounten per gvfs das root-pw?

[spiralnebelverdreher]

Das ist aber seltsam... Warum benötiigst du zum mounten per gvfs das root-pw?

Hmm, gute Frage. Ich vermute mal stark, dass sich das ganz einfach aus den Default-Werten der Installation ableitet. Ich hab da nix geändert.

War ja schon früher so: Mounten darf nur root, es sei denn der mount Befehl ist für bestimmte User zusätzlich frei gegeben oder in der fstab ist für ein bestimmtes Gerät die Option "users" angegeben.

[scientific]

Dann ist es aber auch kein gvfs-mount.
Nimm den mountpunkt mal aus der fstab, und mounte die Partition über nautilus. Dann sollts ohne root-pw gehen.

//EDIT
Les gerade nach, dass die Partition nicht in der fstab ist...

Bist du da GANZ SICHER?

Lg scientific

[spiralnebelverdreher]

Dann ist es aber auch kein gvfs-mount.
Nimm den mountpunkt mal aus der fstab, und mounte die Partition über nautilus. Dann sollts ohne root-pw gehen.
//EDIT
Les gerade nach, dass die Partition nicht in der fstab ist...

Bist du da GANZ SICHER?

Bin da 100% sicher.

Bei diesen ganzen Helferlein-Programmen (erst udev, dann udisks) und Hilfsstrukturen (gfvs, thumbnail-Erzeugung, Suchindex, ...) blicke ich nur oberflächlich durch, ebenso wie bei systemd. Ich kümmere mich da nicht drum, solange es OOB funktioniert. Und wenn ich dann doch mal da reinschaue, erkenne ich schon einereits den Nutzen und zweitens die Komplexität und bin ehrlich gesagt froh, wenn mir hier im Forum jemand sagt, welche der gefühlt 17000 Optionen wie wirkt. Deine Hinweis mit "KillUserProcesses=true" war für mich schon einmal ein sehr guter, auch wenn damit kein umount ausgelöst wird. Aber meinem Ziel, das nach der Session im Zustand wie vor der Session sein soll, bin ich schon mal näher.

Inhaltlich werde ich mich bzgl. des umounts erstmal mit dem von TomL erarbeiteten Ansatz auseinandersetzen.