Rolf_Bensch
Anmeldungsdatum: 25. April 2007
Beiträge: 66
|
Hallo! ein über Jahre gewachsenes Anmeldescript mountet Serververzeichnisse auf den 18.04-Client:
| sshfs $USER@$SERVER:$SRC /home/$USER/$DIR -o ServerAliveInterval=15,reconnect,nonempty,Port=${PORT},IdentityFile=/home/$USER/.ssh/$USER
|
das funktioniert mindenstens seit 12.04 problemlos - auch unter 18.04. Trennt man unter 18.04 allerdings die Netzwerkverbindung (manuell), bleibt gnome für mind. 60 Sekunden hängen. Die Maus funktioniert noch, die Oberfläche reagiert aber auf keinen Klick. In älteren Versionen war das nicht der Fall. Mit STRG-ALT-F3 kann ich in eine andere Console wechseln. Im Syslog finde ich dann: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 | Feb 17 14:31:13 rolf-mini-i7 NetworkManager[895]: <info> [1581946273.8945] device (eno1): state change: activated -> deactivating (reason 'user-requested', sys-iface-state: 'managed')
Feb 17 14:31:13 rolf-mini-i7 NetworkManager[895]: <info> [1581946273.9005] manager: NetworkManager state is now CONNECTED_LOCAL
Feb 17 14:31:13 rolf-mini-i7 NetworkManager[895]: <info> [1581946273.9007] audit: op="device-disconnect" interface="eno1" ifindex=2 pid=2430 uid=1001 result="success"
Feb 17 14:31:13 rolf-mini-i7 NetworkManager[895]: <info> [1581946273.9010] device (eno1): state change: deactivating -> disconnected (reason 'user-requested', sys-iface-state: 'managed')
Feb 17 14:31:13 rolf-mini-i7 dbus-daemon[883]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.10' (uid=0 pid
=895 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Feb 17 14:31:13 rolf-mini-i7 avahi-daemon[930]: Withdrawing address record for fe80::1a03:73ff:fecd:c8b9 on eno1.
Feb 17 14:31:13 rolf-mini-i7 avahi-daemon[930]: Leaving mDNS multicast group on interface eno1.IPv6 with address fe80::1a03:73ff:fecd:c8b9.
Feb 17 14:31:13 rolf-mini-i7 avahi-daemon[930]: Interface eno1.IPv6 no longer relevant for mDNS.
Feb 17 14:31:13 rolf-mini-i7 deja-dup-monito[3392]: Source ID 586 was not found when attempting to remove it
Feb 17 14:31:13 rolf-mini-i7 systemd[1]: Starting Network Manager Script Dispatcher Service...
Feb 17 14:31:13 rolf-mini-i7 dbus-daemon[883]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Feb 17 14:31:13 rolf-mini-i7 systemd[1]: Started Network Manager Script Dispatcher Service.
Feb 17 14:31:13 rolf-mini-i7 nm-dispatcher: req:1 'connectivity-change': new request (2 scripts)
Feb 17 14:31:13 rolf-mini-i7 nm-dispatcher: req:1 'connectivity-change': start running ordered scripts...
Feb 17 14:31:13 rolf-mini-i7 NetworkManager[895]: <info> [1581946273.9659] dhcp4 (eno1): canceled DHCP transaction, DHCP client pid 5424
Feb 17 14:31:13 rolf-mini-i7 NetworkManager[895]: <info> [1581946273.9660] dhcp4 (eno1): state changed bound -> done
Feb 17 14:31:13 rolf-mini-i7 avahi-daemon[930]: Withdrawing address record for 192.168.0.100 on eno1.
Feb 17 14:31:13 rolf-mini-i7 avahi-daemon[930]: Leaving mDNS multicast group on interface eno1.IPv4 with address 192.168.0.100.
Feb 17 14:31:13 rolf-mini-i7 avahi-daemon[930]: Interface eno1.IPv4 no longer relevant for mDNS.
Feb 17 14:31:13 rolf-mini-i7 dnsmasq[1766]: no servers found in /etc/resolv.conf, will retry
Feb 17 14:31:13 rolf-mini-i7 nm-dispatcher: req:2 'down' [eno1]: new request (2 scripts)
Feb 17 14:31:13 rolf-mini-i7 nm-dispatcher: req:2 'down' [eno1]: start running ordered scripts...
Feb 17 14:31:13 rolf-mini-i7 gsd-sharing[2565]: Failed to StopUnit service: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit gnome-user-share-webdav.service not loaded.
Feb 17 14:31:13 rolf-mini-i7 gsd-sharing[2565]: Failed to StopUnit service: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit rygel.service not loaded.
Feb 17 14:31:13 rolf-mini-i7 gsd-sharing[2565]: Failed to StopUnit service: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit gnome-remote-desktop.service not loaded.
Feb 17 14:31:15 rolf-mini-i7 goa-daemon[2500]: goa_http_client_check() failed: 2 — Fehler beim Auflösen von »www.myDomain.de«: Der Name oder der Dienst ist nicht bekannt
Feb 17 14:31:15 rolf-mini-i7 goa-daemon[2500]: /org/gnome/OnlineAccounts/Accounts/account_1581928522_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: Ungültiges Passwort für Benutzer »rolf« (goa-error-quark, 0): Rechnername konnte nicht aufgelöst werden (goa-error-quark, 4)
Feb 17 14:31:15 rolf-mini-i7 org.gnome.Shell.desktop[2430]: [6619:6637:0217/143115.468770:ERROR:connection_factory_impl.cc(420)] Failed to connect to MCS endpoint with error -106
Feb 17 14:31:16 rolf-mini-i7 goa-daemon[2500]: goa_http_client_check() failed: 2 — Fehler beim Auflösen von »www.myDomain.de«: Der Name oder der Dienst ist nicht bekannt
...
Feb 17 14:32:25 rolf-mini-i7 org.gnome.Shell.desktop[2430]: glibtop(c=2430): [WARNING] statvfs '/home/rolf/Server' failed: Eingabe-/Ausgabefehler
Feb 17 14:32:25 rolf-mini-i7 org.gnome.Shell.desktop[2430]: glibtop(c=2430): [WARNING] statvfs '/home/rolf/Server-Fotos' failed: Eingabe-/Ausgabefehler
Feb 17 14:32:25 rolf-mini-i7 org.gnome.Shell.desktop[2430]: glibtop(c=2430): [WARNING] statvfs '/home/rolf/Server-MP3' failed: Eingabe-/Ausgabefehler
|
Das ist nur ein kleines Problem aber manchmal sehr lästig. Es ist auch auf allen 18.04-Installationen reproduzierbar. Hat jemand eine Idee wie ich das beheben kann?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Rolf_Bensch schrieb: […] Trennt man unter 18.04 allerdings die Netzwerkverbindung (manuell),
Brutal!!!
bleibt gnome für mind. 60 Sekunden hängen. […]
Das klingt jetzt nicht so völlig überraschend. Oder wunderst Du Dich auch, wenn nach dem Einsturz einer Brücke alle Autos abstürzen? Verwunderlich ist allenfalls, dass es früher keine Probleme gab.
Hat jemand eine Idee wie ich das beheben kann?
Hast Du schon versucht, die Netzlaufwerke vor dem Abbau der Netzwerkverbindung sauber auszubinden?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Rolf_Bensch schrieb: Hat jemand eine Idee wie ich das beheben kann?
Hallo! Das von dir beschriebene Verhalten war schon früher so. Falls du ohne das reconnect leben kannst, wird der "Hänger" kürzer. Das Problem bei einer plötzlich getrennten Verbindung ist, dass das fuse-Modul versucht die noch fehlenden Daten zu Schreiben und den Wiederaufbau zu schaffen, was alle Programme, die mit dem externen Speicher verbunden sind (Dateimanager, Konsole im entsprechenden Verzeichnis, Editor mit externer Datei, etc.) in eine "unbenutzbare Warteschleife" schickt. Falls du derjenige bist, der die Verbindung trennt: Erstell dir ein Script, welches VOR dem Trennen für jeden mount ein lazy unmount durchführt - also fusermount -zu <Einhängepunkt> . Im Falle des NetworkManagers geht das mittels NetworkManager/Dispatcher.
|
Rolf_Bensch
(Themenstarter)
Anmeldungsdatum: 25. April 2007
Beiträge: 66
|
Hallo! ChickenLipsRfun2eat schrieb: Rolf_Bensch schrieb: Hat jemand eine Idee wie ich das beheben kann?
Hallo! Das von dir beschriebene Verhalten war schon früher so. Falls du ohne das reconnect leben kannst, wird der "Hänger" kürzer.
Hmmm, das ist nicht wirklich kürzer.
Das Problem bei einer plötzlich getrennten Verbindung ist, dass das fuse-Modul versucht die noch fehlenden Daten zu Schreiben und den Wiederaufbau zu schaffen, was alle Programme, die mit dem externen Speicher verbunden sind (Dateimanager, Konsole im entsprechenden Verzeichnis, Editor mit externer Datei, etc.) in eine "unbenutzbare Warteschleife" schickt.
Das ist grundsätzlich nachvollziehbar. Das aber auch wieder nicht vor dem Hintergrund, dass bislang kein anderes Betriebssystem so reagiert hat. Notebook-Besitzer, die regelmäßig seinen Soft- oder Hardwareschalter für WLAN verwenden stehen hier sicher vor einem Problem.
Falls du derjenige bist, der die Verbindung trennt: Erstell dir ein Script, welches VOR dem Trennen für jeden mount ein lazy unmount durchführt - also fusermount -zu <Einhängepunkt> . Im Falle des NetworkManagers geht das mittels NetworkManager/Dispatcher.
Das ist ein guter Gedanke. Jedoch ein Auszug aus 01if_updown: | # pre-up/pre-down not implemented. See
# https://bugzilla.gnome.org/show_bug.cgi?id=387832
# pre-up)
|
Ich habe testweise die Kommentare entfernt, ein pre-down-Event wird tatsächlich nicht ausgelöst. Der verlinkte bugzilla-Beitrag endet in 2004. Das Aushängen über den down-Event kommt zu spät (der PC hängt wieder).
|
Rolf_Bensch
(Themenstarter)
Anmeldungsdatum: 25. April 2007
Beiträge: 66
|
kB schrieb: Rolf_Bensch schrieb: […] Trennt man unter 18.04 allerdings die Netzwerkverbindung (manuell),
Brutal!!!
wieso? Eine Netzwerkverbindung kann immer mal offline gehen. Sei es durch Stromausfall, Störung am Netzknoten oder Switch, den Schalter am PC...
bleibt gnome für mind. 60 Sekunden hängen. […]
Das klingt jetzt nicht so völlig überraschend. Oder wunderst Du Dich auch, wenn nach dem Einsturz einer Brücke alle Autos abstürzen? Verwunderlich ist allenfalls, dass es früher keine Probleme gab.
das finde ich nicht. Ich denke, das sollte ein BS schon sauber abfangen können.
Hat jemand eine Idee wie ich das beheben kann?
Hast Du schon versucht, die Netzlaufwerke vor dem Abbau der Netzwerkverbindung sauber auszubinden?
Ja. Leider wird beim dispatcher "pre-down" nicht mehr ausgelöst und "down" kommt zu spät - der PC hängt dann bereits.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Rolf_Bensch schrieb: Ich habe testweise die Kommentare entfernt, ein pre-down-Event wird tatsächlich nicht ausgelöst. Der verlinkte bugzilla-Beitrag endet in 2004. Das Aushängen über den down-Event kommt zu spät (der PC hängt wieder).
Oh, schade. Ich nutze den NM nicht, deswegen hatte ich mich da einfach mal drauf verlassen, dass der das kann ☺ Der systemd-Weg wäre in etwa so: [Unit]
Wants=network-online.target
After=network.target network-online.target
[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/path/to/script
RemainAfterExit=yes
Kurz erklärt: Beim Start wird lediglich /bin/true aufgerufen, damit die Unit erfolgreich startet. Da systemd alle Dienste in umgekehrter Reihenfolge beendet, kann man beim ExecStop das eintragen, was ausgeführt werden soll. Das ganze darf natürlich auch eine user-Unit sein. Ich nutze das allerdings beim Herunterfahren des Systems, ob das bei dir so klappt musst du ausprobieren. Falls das auch nicht klappt, müsste man ggf. mittels UDEV das Ereignis abfangen, das beim Schalter umlegen auftritt.
|
Rolf_Bensch
(Themenstarter)
Anmeldungsdatum: 25. April 2007
Beiträge: 66
|
Gerade mal xfce4 installiert. Hier tritt das Problem nicht auf.
|
Rolf_Bensch
(Themenstarter)
Anmeldungsdatum: 25. April 2007
Beiträge: 66
|
Habe mich mal an systemd versucht. Der Service startet: | mini-i7:~$ systemctl --user status umountServer.service
● umountServer.service - umount user-mounts (Server*)
Loaded: loaded (/etc/systemd/user/umountServer.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2020-02-19 14:16:48 CET; 6min ago
Process: 2299 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 2299 (code=exited, status=0/SUCCESS)
Feb 19 14:16:48 rolf-mini-i7 systemd[2287]: Starting umount user-mounts (Server*)...
Feb 19 14:16:48 rolf-mini-i7 systemd[2287]: Started umount user-mounts (Server*).
|
So sieht das Servie-File aus: 1
2
3
4
5
6
7
8
9
10
11
12
13
14 | mini-i7:~$ cat /etc/systemd/user/umountServer.service
[Unit]
Description=umount user-mounts (Server*)
Wants=network-online.target
After=network.target network-online.target
[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/usr/local/02_UmountUserHome.sh
RemainAfterExit=yes
[Install]
WantedBy=basic.target
|
Das zugehörige Script: | mini-i7:~$ cat /usr/local/02_UmountUserHome.sh
umount /home/rolf/Server*
logger -t systemd "umount: err $?"
exit 0
|
Sollte zumindest, wenn das Netzwerk getrennt wird, eine Ausgabe nach syslog erzeugen - tut es aber nicht. Wie kann ich feststellen weshalb ExecStop nicht ausgeführt wird?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ich würde im Script mit absoluten Pfaden arbeiten. Außerdem fehlt noch eine Shebang. Testen könntest du das mit bspw. #!/bin/bash
/usr/bin/logger Kaffee ist Leben! Das ist dann die aktuelleste Meldung in journalctl -xe .
|