Netzwerk mount in fstab bei systemd

[subson]

Ich habe auf dem Laptop in der fstab folgenden Pfad für meine NFS Freigabe stehen.

Code: Alles auswählen

IP.zum.Ser.ver:/mnt/Pfad        /mnt/Pfad   nfs     rw,hard,intr,noauto,x-systemd.automount     0       0

Seid dem update auf stable v 8, habe ich beim herunterfahren eine "Stop Job is running" Meldung. Interessanter Weise ist diese Meldung nicht immer. Ins Netzwerk melde ich mich entweder mit LAN oder aber WLAN an, je nachdem.

Swap habe ich auskommentiert, da war ja auch der Fehler, aber hier, weiß ich nicht was da hin muß.

[gugus]

Servus

Genau dasselbe Problem habe ich auch, schon einiger Zeit.
Kann es auch nicht irgendwie eingrenzen ausser dass mein Laptop nur am Wlan hängt.

Es ist beim Booten und wenn ich den Laptop herunterfahre.

Die mounts sind in fstab eingetragen, die Parameter sind:
nfs rw,user,exec 0 0

Aus den Logs werde ich nicht schlau.

Gruss
Gugus

[TomL]

Genau dasselbe Problem habe ich auch, schon einiger Zeit. Kann es auch nicht irgendwie eingrenzen ausser dass mein Laptop nur am Wlan hängt. Es ist beim Booten und wenn ich den Laptop herunterfahre. Die mounts sind in fstab eingetragen, die Parameter sind:

Ja, da gibt es ein bekanntes Problem. Anscheinend wird die WLAN-Hardware abgeschaltet, bevor die Mounts getrennt sind. Dann hängt natürlich das Runterfahren in diesen 120-Sekunden-Stop-Jobs. Das ist aber relativ einfach zu lösen, und zwar in dem Du die Mounts eben von Hand vor dem shutdown "umountest". Am einfachsten ist es, wenn Du Dir ein shutdown-Icon auf den Desktop legst, etwa mit folgendem Inhalt:

Code: Alles auswählen

#!/bin/bash
/etc/init.d/umountnfs.sh   >/dev/null 2>&1
/bin/systemctl poweroff -i >/dev/null 2>&1
exit 0

Damit sollten vor dem Shutdown die verbundenen Mounts getrennt werden und das System flüssig runterfahren.

[smutbert]

Hab ihr es schon mit den Mountoptionen

Code: Alles auswählen

x-systemd.automount,x-systemd.requires=network-online.target

versucht?

Letztere sollte dafür sorgen, dass erst versucht wird zu mounten, wenn die Netzwerkverbindung bereits zur Verfügung steht und noch geunmountet wird solange die Verbindung noch zur Verfügung steht.

[subson]

Leider funktioniert beides bei mir nicht.

Der fstab Eintrag brachte keine Änderung, beim scribt bleibt das Laptop beim runterfahren stehen.

[TomL]

Der fstab Eintrag brachte keine Änderung, beim scribt bleibt das Laptop beim runterfahren stehen.

Was bedeutet "beim Script bleibt....stehen" ? Was meinst Du damit?

Versuche bitte mal folgendes, vor dem Herunterfahren.... nur um klar festzustellen, ob das wirklich die Ursache ist. Öffne ein Terminal, melde dich als root an und gib folgende Zeile ein:

Code: Alles auswählen

/etc/init.d/umountnfs.sh

Dann kannst Du das Terminal schließen und den Laptop ganz normal runterfahren. Achte jetzt drauf, ob er sofort (nach einigen Sekunden) ausschaltet, oder ob er trotzdem noch hängt. Wenn er nicht hängt, waren die mounts das Problem, wenn er trotzdem hängt, gibts ein anderes Problem.

[gugus]

wäre es eine Möglichkeit das unmount script in den shutdown oder restart einzubauen.

[gugus]

Sodele, habe es gerade ausprobiert.

Der Tip von smutbert hats gebracht, danke.

Ich habe "stretch" mit aktuellem update auf meinem Laptop und die Zeile wie oben beschrieben in meine fstab eingebaut:

Code: Alles auswählen

192.168.1.90:/srv/download /home/rdu/Download nfs rw,user,exec,x-systemd.automount,x-systemd.requires=network-online.target       0       0
192.168.1.90:/srv/bilder /home/rdu/Bilder nfs rw,user,exec,x-systemd.automount,x-systemd.requires=network-online.target   0       0
192.168.1.90:/srv/mp3 /home/rdu/Musik nfs rw,user,exec,x-systemd.automount,x-systemd.requires=network-online.target       0       0

Der Laptop fährt ohne countdown runter und bootet wieder gewohnt schnell ohne Wartezeit.

Danke & Gruss
gugus

[subson]

Bei dem script bleibt der Rechner in der Eingabeaufforderung ...debian... login... stehen.

Auch mit

Code: Alles auswählen

/etc/init.d/umountnfs.sh

kommt der Stop Job.

[TomL]

Bei dem script bleibt der Rechner in der Eingabeaufforderung ...debian... login... stehen.
Auch mit

Code: Alles auswählen

/etc/init.d/umountnfs.sh

kommt der Stop Job.

Wie ist die Meldung im Terminal nach dem umountnfs? Kommt überhaupt eine (Fehler-)meldung... was passiert, wenn Du das im Terminal absendest? Gib im Terminal NACH dem umountnfs einmal

Code: Alles auswählen

df -h

ein, um zu sehen, ob die mounts wirklich getrennt sind. Und dann prüfen, wie der Shutdown verläuft. Wie lautet die Meldung bei diesem Stop-Job?

Und ganz wichtig.... hast Du den Eintrag in der fstab (smutberts Vorschlag) vorgenommen? Und danach den Rechner neu gestartet? Es kann sein, das network-online.target NICHT aktiviert war, wenn vorher kein anderer Prozess eine Abhängigkeit auf dieses Target definiert hat. In solchen Fällen wird network-online-target einfach nicht berücksichtigt.... und natürlich auch nicht beim reversen Ablauf des nächstens Shutdowns. Das bedeutet, nach der Änderung einmal starten und prüfen, obs jetzt geht.

[smutbert]

Stimmt, das hätte ich erwähnen sollen: Damit die Mountoptionen wirksam werden ist ein Neustart notwendig, damit Systemd die mount-units neu erstellt. Es hilft auch nichts, wenn network-online.target bereits aktiv war.

[TomL]

Es hilft auch nichts, wenn network-online.target bereits aktiv war.

Nur 'n kurzer Hinweis.... network-online.target ist nicht beste Wahl. network-online.target wird direkt nach network.target gestartet. Das Problem ist, dass network.target aber keinen eindeutig definierten Zustand hat.... der Zustand ist primär vom Networkmanager definiert. Das kann bedeuten... von "Networkmanager ist gestartet" bis "IP ist gegeben" und alles dazwischen ist möglich. Dann ist noch die Frage, wie das Ergebnis ist, wenn gar kein Networkmanager installiert ist und stattdessen /etc/network/interfaces verwendet wird.

Fazit: network-online.target kann gut gehen, muss aber nicht. Ich verwende auf meinen Rechnern (ohne Network-Manager)

Code: Alles auswählen

systemd-networkd-wait-online.service

Das klappt prima, sogar auf lahmen WLAN-Verbindungen, die beim Systemstart wirklich lange bis zur DHCP-IP brauchen. Die mounts warten geduldig, bis das Netzwerk lebt und sie dran sind, sogar wenn sie über mein mountctrl-script erstellt werden. Das ist echt spannend... das Script wird relativ früh gestartet, nach dem Netzwerk, aber die Mounts selber kommen dann völlig abgekoppelt viel später. Das heisst, systemd handhabt das richtig clever.

[smutbert]

Das kannte ich noch gar nicht. Laut manpage hat das aber nichts mit network-manager am Hut sondern berücksichtigt nur die systemd-eigene Möglichkeit zur Konfiguration der Netzwerkinterfaces (systemd-networkd), hilft also also allen, die ihr Netzwerk entweder über einen Netzwerkmanager wie network-manager und wicd oder althergebracht über die »/etc/network/interfaces« konfigurieren nicht weiter.


Wenn network-online.target nicht ausreicht (was es imho trotz der möglichen Unzulänglichkeiten meistens tut) dann gäbe es noch NetworkManager-wait-online.service, das speziell für den Fall von network-manager prüft ob eine Netzwerkverbindung besteht. Es müsste sich also ev. statt network-online.target verwenden lassen.

[mistersixt]

network-online.target, oder systemd-networkd-wait-online.service, oder doch vielleicht NetworkManager-wait-online.service ... oder sogar kombiniert? Wieder mal "ein dreifach donnerndes Helau" auf das moderne systemd ...

[TomL]

network-online.target, oder systemd-networkd-wait-online.service, oder doch vielleicht NetworkManager-wait-online.service ... oder sogar kombiniert? Wieder mal "ein dreifach donnerndes Helau" auf das moderne systemd ...

Welche Hinweise kann ich jetzt zur Lösung des eigentlichen Thread-Problems daraus ableiten? Oder war das vielleicht gar nicht als Hilfe gedacht und das eigentliche Thema wurde einfach ignoriert?