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?

[TomL]

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.

Ja, ich denke auch, dass das target im Normalfall bei eth0 ausreicht. Die Probleme bestehen aber bei WLAN-Verbindungen. Und da klappts aber mit NetworkManager-wait-online.service auch nur, wenn die Unit überhaupt da ist... und das ist sie nur, wenn ein Network-Manager installiert ist. In meiner OpenBox-Installation fehlt sie, in der LXDE-VM ebenfalls. Die Unit ist allerdings in XFCE vorhanden und macht nix anderes, als den Network-Manager zu fragen, ob das Netz bereit ist. *hmmmm* Ne richtige und überall-wirksame Lösung ist das also auch nicht.

Die von mir genannte Unit systemd-networkd-wait-online.service gibts aber auf allen Systemen. Den Hinweis dazu habe ich (s.u.) gefunden, wobei ich aber nicht ausschließe, dass ich da vielleicht auch mangels unzureichender English-Kenntnisse was missverstanden habe. Allerdings führte das dazu, dass mein Script definitiv nach dem Netzwerk gestartet wurde.... eindeutig zu sehen im Systemd-Boot-Plot. Und trotzdem hatte ich die Situation, dass die Verbindung zum Server auf Grund des Wartens auf ne DHCP-IP noch nicht vorhanden war.
http://www.freedesktop.org/wiki/Softwar ... orkTarget/

[smutbert]

Ja, ich halte es eigentlich für einen Fehler, dass network-online.target nicht die Lösung ist, die immer zuverlässig funktioniert. Wenigstens hält sich bei den systemd-units der Aufwand sie nach den eigenen Bedürfnissen anzupassen sehr in Grenzen.

[subson]

Code: Alles auswählen

rw,hard,intr,noauto,x-systemd.automount,x-systemd.requires=network-online.target

Das sind jetzt die mount Parameter, so hatte ich sie getestet und es so gelassen, auch bei den umountnfs Tests.

Nach umountnfs in der Konsole kommt keine Meldung, df -h zeigt die nfs mounts immer noch aktiv.

Code: Alles auswählen

systemd-networkd-wait-online.service

Schaltet die mounts aus, sie sind also gar nicht erreichbar, dann ist zwar der Stop Job Fehler weg, aber die NFS mounts auch.

[smutbert]

Schaltet die mounts aus, sie sind also gar nicht erreichbar, dann ist zwar der Stop Job Fehler weg, aber die NFS mounts auch.

weil vermutlich, wie ich schon geschrieben habe, systemd-networkd-wait-online.service nur die Netzwerkinterfaces berücksichtigt, die auch von systemd-networkd konfiguriert werden und bei dir wird vermutlich kein einziges so konfiguriert.

Bevor ich zur ersten Hälfte deines Posts auch noch etwas schreibe muss ich etwas ausprobieren…

[TomL]

Moin

Ich habe mich jetzt noch mal ein bisschen erneut mit dem Thema beschäftigt.... erneut deshalb, weil das auch auch für mich bestehende alte Probleme sind. Fakt ist, die Probleme haben m.E. überhaupt nichts mit systemd zu tun und können auch nur indirekt über systemd gelöst werden. Das Problem des hängenden Shutdowns bei Wifi-Cifs-Mounts findet man schon im Jahr 2010.... also lange vor systemd.

Aber es gibt ja 2 Probleme, neben dem hängenden Shutdown eben auch die Boot-Phase, in der die fstab-Einträge irgendwann zu mounten versucht werden, was mitunter auch fehlschlägt oder in zig Fehlermeldungen resultiert, bis es irgendwann dann doch erfolgreich ist. Ich habe das jetzt über eine systemd-unit gelöst, die zumindest die Bootphase vernünftig abhandelt und auch wirklich wartet, dass die Freigaben zum mount via Wifi tatsächlich verfügbar sind, völlig unabhängig wie diverse Network-Manager ggf. den Zustand "network-online.target" bewerten und unabhängig von dem Zeitpunkt, wann sie ihn "anziehen".

Denn flüssigen Shutdown mit offenen Wifi-Cifs-Mounts kriegt man nur hin, wenn die Mounts vorher getrennt werden. Ich vermute, dass die Wifi-Hardware durch das Shutdown-Ereignis einfach abgeschaltet wird.... und das es anscheinend kein pre-closing-Event gibt, um Anwendungen zu informieren und ihnen eine Reaktion zu ermöglichen. Ich bin jetzt mal gespannt, welche Erkenntnisse smutbert beim Testen noch gewinnt....

[subson]

Cifs habe ich zum Glück nicht, nur NFS Freigaben.

Da ich nicht automatisch mit Wifi oder Lan verbinde, sondern manuell, hatte ich beim booten auch immer Fehlermeldungen, die aber mit "noauto" unterbunden habe.

[TomL]

Da ich nicht automatisch mit Wifi oder Lan verbinde, sondern manuell, hatte ich beim booten auch immer Fehlermeldungen, die aber mit "noauto" unterbunden habe.

Systemd startet Dienste parallel in Abhängigkeit von den Einstellungen in den Service-Units.... und genau das macht es auch wirklich gut. Die Probleme resultieren m.E. daraus, dass die darauf folgenden Prozesse das als Folge ihres sysvinits-Erbes noch nicht so richtig umsetzen können. systemd startet das Netzwerk und das Filesystem und überlässt anscheinend diesen Prozessen selber sicherzustellen, mit den gegenseitigen Abhängigkeiten klarzukommen.... was meiner Meinung nach auch gar nicht Sache von systemd wäre.

Also, wenn Filesystem und Network beim Boot gestartet sind, dann heisst das noch lange nicht, das Filesystem aufs Network zugreifen kann. Daraus resultiert, die mounts produzieren haufenweise Fehlermeldungen, weil das Network erstmal ne Verbindung aufbauen muss und z.B. auf die DHCP-IP warten muss und weil die mounts es trotzdem immer wieder erneut versuchen. An meinem alten Xfce-Laptop 2 Haus-Etagen (der Härtefall!) unter dem Router dauert nur die Wlan-Netzverbindung mitunter 20-25 Sekunden, die das Netzwerk für den Connect benötigt, während dessen ständig versucht wird, zu mounten.

Das Problem ist hier der schwammige Zustand mit dem network-online.target, welches zu irgendeinem Zeitpunkt vom Networkmanager oder von Wicd angezogen wird, Aber es ist nicht bekannt, wann.... und es muss nicht bedeuten, dass der Rechner in dem Moment auch wirklich mit dem Netz verbunden ist. Es kann auch einfach nur bedeuten, "ein NIC ist up" oder "Networkmanager ist gestartet". Aber es bedeutet nicht "IP ist vorhanden, das Netz ist verbunden". Systemd ist das anscheinend (zu Recht) alles egal, es hat beide "Dienste" fehlerlos gestartet. Völlig unklar ist die Situation, wenn weder NM noch Wicd arbeiten.... vermutlich zieht systemd network-online.target dann selber einfach nach dem network.target an, obwohl das Netzwerk möglicherweise noch gar nicht abschließend verbunden ist.

Schwierig wird die Situation dadurch, dass es bei Debian keine Einheitlichkeit gibt.... xfce und cinnamon verwenden den NM, lxde verwendet Wicd, mein Eigenbau-Destop ist direkt konfiguriert und verwendet gar keinen Network-Manager. Und dann besteht noch der ebenfalls vernebelnde Effekt, dass der Fehler z.B. bei den eth0-Laptops nicht auftritt.... die Kabel-Verbindung ist meistens so schnell, dass es gar nicht erst zu Fehlern kommt. Und das viele Laptops sich zwar mit dem Netz verbinden, aber nix im Netz mounten. Das bedeutet, der Fehler tritt nur bei einem kleineren Anteil von allen Laptops auf.

Also, lange Rede, kurzer Sinn.... die Fehlermeldungen beim Booten beseitigt man mit "Network->Eindeutigkeit" vor dem Mounten. Das halte ich für die bessere Alternative bezüglich noauto. Eindeutigkeit bedingt, am Besten das network-online.target völlig zu ignorieren und selber über eine Unit + Script zu gucken, ob das Netz da ist. Das funktioniert bei mir jetzt fehlerfrei und ohne zusätzliche Verzögerungen. Damit ist die Bootphase geregelt und es funktioniert immer.

Das nächste Problem ist der Shutdown.... und dort wiederum auch nur, wenn es sich um einen wifi-Connect und offene Netzwerk-Mounts handelt. Das, was ich bisher herausgefunden habe, ist der Umstand, dass dbus anscheinend vor dem Network-Manager weg ist. Der NM ist also machtlos und kann niemand über das zu schliessende Netz informieren. Und wenn dbus weg ist, klappt natürlich genau deswegen ab dem Moment auch der umount nicht mehr... mit dem Ergebnis des hängenden Shutdowns beim 120-Sekunden-Stopjob. Aber auch hier ist anscheinend nicht systemd das Problem, sondern unzureichendes Customizing der nachgeschalteten Units, die vielleicht einfach nur ein After=dbus.service benötigen. Das werde ich morgen mal prüfen. Ich würde mich freuen, wenn smutbert vielleicht noch mal mitwirken würde.... denn mehr Sachverstand ist wohl schwer zu finden.

Was mich aber jetzt noch interessiert.... rück mal ein paar Infos über Dein System raus.... welches Debian, welcher Desktop, wie ist das Netzwerk konfiguriert (NM oder direkt), wie sind die mounts in der fstab eingetragen?

[subson]

Debian 8.2 mit KDE, das Netzwerk habe ich mit dem Network Manager eingerichtet, die mounts habe ich selbst in die fstab eingetragen.

[TomL]

Hallo

Es tut mir sehr leid, aber ich muss passen.... ich kann Dir leider bei Deinem Problem nicht helfen. Ich kenne den Fehler, ich kann ihn auf meinen Laptop's beliebig reproduzieren, ich kann ihn natürlich auch jederzeit beseitigen, ich kenne den Verursacher und die Maßnahmen dagegen. Nur ist das leider etwas, was nicht mit ein paar Klicks irgendwo eingestellt werden kann, sondern ein wenig Erfahrung mit dem CLI bedarf.

Fakt ist: Der Networkmanager ist der Verursacher, weil er definitiv die WLAN-Hardware abschaltet, ohne vorher die Netzwerkverbindungen zu lösen. Meines Erachtens trifft das zu, was ich vorher schon vermutet habe, der NM hat noch nicht absschliessend die Veränderungen mit Systemd verinnerlicht. Deaktiviere ich zuerst den NM und trage dann die Netwerkverbindungen in die /etc/network/interfaces ein, kann ich präzise an Hand des Journals feststellen, dass Systemd sich absolut sauber an die umgekehrte Boot-Reihenfolge der Unit-Direktiven hält und die Wifi-Verbindung erst dann abschaltet, nachdem alle Prozesse ordentlich aufgeräumt haben.... mit dem Ergebnis, dass der Shutdown ohne Fehlermeldungen flüssig durchläuft. Es ist eindeutig feststellbar, dass der umount bei beiden Rechnern etwa 5-6 Sekunden nach dem "systemctl poweroff" durchgeführt wird und weitere zig Sekunden danach erst Wifi von systemd abgeschaltet wird. Die 5-6 Sekunden nach Poweroff ist die Regel auf beiden Maschinen! Der NM hingegen schaltet schon vor Ablauf der 1. Sekunde nach "Poweroff" das Wifi aus... danach hat kein Prozess mehr die Chance das "Netzwerk" aufgeräumt zu verlassen... die mounts hängen in den 120-Sekunden-Stopjobs. Das ist durch nichts zu verhindern. Kriegt der NM ein Signal, Kill oder Term oder wasauchimmer, knallt er das Wifi auf beiden Rechnern sofort weg.

Die Bootphase habe ich über eine eigene Unit "network_wait_online" geregelt, die absolut zuverlässig darauf wartet, dass der Rechner auch wirklich mit dem Netz verbunden ist, also das er eine gültige IP hat. Interessant wäre jetzt das Ergebnis, wie sich "x-systemd.requires=network_wait_online" in der fstab auswirkt, da "requires" als requires und after interpretiert wird. Das sollte eigentlich gut funktionieren und dürfte keinen negativen Einfluss auf den Bootvorgang haben.... bis nach Ablauf des Timeouts im Hintergrund die Bemühungen zu mounten eingestellt werden, wenn das Netzwerk nicht verfügbar ist.Davon sollte man aber nix mitkriegen, allenfalls das Journal. Aber um auch das wiederum eindeutig zu gestalten und selber die Kontrolle zu haben, habe ich das ebenfalls über eine eigene Unit mountctrl geregelt, die eben mit genau diesen wechselnden Situationen klar kommt, wenn mal das Netz da, mal ein Netz da ist, mal der Server da ist, und mal gar nix da ist.

Und um den Kreislauf Boot und Shutdown mit einer weiteren Komponente zu vervollständigen und weil ich natürlich nicht auf den grundsätzlichen Komfort eines NM verzichten möchte, nutze ich dafür einen eigenen rudimentären Script-NM, mit dem ich wechselnde (vor-konfigurierte) Netze komfortabel verbinden und lösen kann.

Das Problem ist jetzt, dass ich bei der Ursachensuche wegen der Probleme beim Shutdown auf einmal über diesen Fehler gestolpert bin:

Code: Alles auswählen

Jan 09 14:53:58 Dell-Laptop colord[878]: (colord:878): Cd-WARNING **: failed to get session [pid 816]: Unbekannter Fehler -2
Jan 09 14:54:10 Dell-Laptop colord[878]: # ERROR: snmp_send failed, Network is unreachable
Jan 09 14:54:10 Dell-Laptop colord[878]: # ERROR: snmp_send failed, Network is unreachable

Erwähnenswert ist, dass das Netz gestartet ist und das ich colord sogar "after network_wait_online" konfiguriert habe.... interessiert ihn aber nicht. Möglicherweise guckt er nur auf den Zustand des NM, der aber jetzt im Moment nicht lebt. Ich habe keine Ahnung, ob ich diesen Fehler jetzt verursacht habe, ob es da überhaupt einen Zuammenhang gibt, was das bedeutet, wofür colord überhaupt verwendet wird und ob der vielleicht schon immer besteht. Dummerweise habe ich wegen der Fehersuche auch erst heute das Journal aktiviert... also kann ich nicht nachsehen, obs den früher schon gab. Und da Du die KDE verwendest, die ebenfalls den Networkmanager beinhaltet, möchte ich jetzt lieber keinen Rat geben, wenn die Gefahr besteht, dass danach andere Fehler bestehen, bzw., das danach vielleicht gar nix mehr geht.

Das einfachste wäre jetzt (was auch auf jeden Fall funkioniert), ein Shutdown-Desktop-Icon, welches auf ein kleines Script verweist, mit dem zuerst "umount'ed" wird und dann erst "poweroff" ausgeführt wird. In Verbindung mit noauto in der fstab wären damit also die Probleme gelöst, ohne sich in Gefahr zu begeben, was kaputt zu machen.

[subson]

Danke sehr für Deine ausführliche Beiträge, jetzt ist mir auch klarer wie das zusammen hängt. Hatte ich doch innerlich systemd verflucht.

Ein shutdown script wäre ja auch möglich, als Übergang.

Im Moment streikt nur mein Server, -> anderes Thema hier im Bereich, deshalb habe ich die mounts vorerst auskommentiert.