Ich hatte ja den Bugreport gemacht. Bisher hat sich kein Entwickler geäußert oder den Bug bestätigt oder übernommen. Falls das von mir im Bugreport geschilderte Szenario auf euch zutrifft, dann möchte ich mal dafür werben euch in den Bug mit einzuklinken, falls ihr einen launchpad oder ubuntuone account habt. Einfach auf "Bug affects me too" oder sowas klicken. Dann müsste er mehr "Heat" und damit Aufmerksamkeit bekommen. Schließlich sind wir ja alle an einer Behebung interessiert.
NFS / SMB Mount - Fstab - Bootprobleme
Anmeldungsdatum: Beiträge: Zähle... |
|
||||||||||
Anmeldungsdatum: Beiträge: 700 Wohnort: Bayern |
Hallo Talaureth, ich habe auch einen (separaten) Report eröffnet, da du ja mit "boot"Problemen kämpfst. Ich allerdings ausschließlich mit Shutdownproblemen. Ich bin mir zwar nicht sicher, ob die Ursache nicht sogar die gleiche ist, allerdings äußert sich der Fehler hald bei mir anders... Hier der Link für das Shutdown-Problem: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1577885 |
||||||||||
Anmeldungsdatum: Beiträge: Zähle... Wohnort: In der Nähe vom Mond |
Ich hänge mich mal ein, denn ich habe das gleiche Problem. Kurios dabei ist, dass das Problem bei einem Laptop mit Ubuntu (Unity) nicht auftritt, bei einem mit XUbuntu bestückten Laptop aber schon. Beide sind im selben Netzwerk und haben für die Netzlaufwerke angepasste fstabs. Auch wenn die Laptops verschiedene Fabrikate sind (1. Dell, 2. Samsung) ist der Hauptunterschied, dass der Dell eine SSD-Platte eingebaut hat und der Samsung nicht. Dell hängt per Kabel am Netzwerk, Samsung über WLan. Allerdings konnte ich die Art der Verbindung schon ausschließen, denn auf dem Samsung mit XUbuntu werden die Netzlaufwerke auch nicht über Kabel eingehangen. Haue ich die Werte auto,x-systemd.automount mit in die fstab-Zeile, funktioniert zwar das Einhängen, allerdings zeigt Thunar das Netzlaufwerk doppelt an (einmal als Netzlaufwerk und einmal als Festplatte) und es kommt zu der starken Verzögerung beim Shutdown, wie Acer54 schreibt. |
||||||||||
Anmeldungsdatum: Beiträge: 700 Wohnort: Bayern |
Mittlerweile bin ich etwas weiter was das Umount-Problem angeht. Ich hab mittlerweile folgenden systemd-Service angelegt:
das dazugehörige Script, das aufgerufen wird:
welches man ausführbar machen muss mit:
Nun den Service noch aktivieren und den Systemd-Daemon neu starten
Damit wird bei jedem Stop-Aufruf des Systemd-Dienstes "multi-user.target" das o.g. Script ausgeführt. Dies umounted die Laufwerke. Hier mal meine Fstab, da "Einhängen" ja schon immer bei mir funktioniert hat:
Später habe ich nur einen Starter unter .config/autostart, der "mount -a" ausführt. Damit werden die vorbereiteten Mounts eingehängt. |
||||||||||
Anmeldungsdatum: Beiträge: 7990 |
Das Problem,dass die Netzwerk-Verbindung unterbrochen wurde, bevor die Freigaben ausgehängt sind, ist leider uralt und schon X-mal durchgekaut. Es war – leider offenbar nur vorübergehend ☹ – weitgehend gelöst worden. Das Workaround von Acer54, die Freigaben vor dem Shutdown auszuhängen, funktioniert natürlich. Aber es ist keineswegs ungefährlich, sofern nicht vorher überprüft wird, ob nicht irgend ein Anwendungsprogramm noch auf eine der Freigaben zugreift und diese noch geöffnet hat. Deshalb werden die Freigaben in der normalen Shutdown-Sequenz erst dann ausgehängt, wenn alle Anwendungsprogramme geschlossen sind. Der richtige Zeitpunkt für das Aushängen der Freigaben ist also nach dem Schließen der Anwendungsprogramme (auch Daemonen) und vor dem Trennen der Netzwerkverbindung. Mit dem Network-Manager ist dies offenbar schwierig zu machen (?), denn er ist im Grunde selbst ein Anwendungsprogramm/Daemon. Als Erweiterungen des Workaround von Acer54 wurden deshalb schon vor Jahren recht komplizierte Skripte vorgeschlagen, die zuerst nach Anwendungen suchen, die noch mit Samba- bzw. NFS-Freigaben verbunden sind, und diese dann vor dem Aushängen der Freigaben schließen. Wirklich befriedigt hatte aber keines davon. Wenn nicht eine Überarbeitung der Boot- bzw. Shutdown-Sequenz (was wohl wegen evtl. weitreichender Folgen schwierig ist) die Lösung bringt, sehe ich nur folgende Möglichkeiten:
Gruß – Max-Ulrich |
||||||||||
Anmeldungsdatum: Beiträge: 700 Wohnort: Bayern |
Hallo Max-Ulrich, danke für die nähere Erläuterung! Ich habe mich mit solchen Themen (Gefahr durch Umount vor dem Herunterfahren) nicht sonderlich auseinandergesetzt... ich hatte erst einmal Interesse daran, dass die Kiste in einer (für eine SSD) annehmbaren Zeit herunterfährt. Ein, zwei Verständnisfragen hätte ich aber dennoch:
Vielen Dank schon mal für die Hilfe. Acer |
||||||||||
Anmeldungsdatum: Beiträge: 7990 |
Hallo Acer54, Ich weiß nicht, ob ich Deine Fragen zufriedenstellend beantworten kann.
Offensichtlich ist das bei Samba nicht unbedingt der Fall. Die Verhältnisse sind da auch etwas komplizierter, da beim Server ja auch verschiedene Betriebssysteme möglich sind. Ich denke, dass beim Aushängen der Freigabe wohl schon der Samba-Puffer noch übertragen wird, doch wenn ein Anwendungsprogramm einen eigenen Puffer unterhält (bei Schreibprogrammen, Bildbearbeitungen usw. ja üblich), dann können diese Daten vermutlich verloren gehen. Ich selbst habe da keine Erfahrungen, aber ganz harmlos scheint dies jedenfalls nicht zu sein.
Beim regulären Shutdown wird der NetworkManager erst dann abgeschaltet, wenn die nach dem Einloggen gestarteten Anwendungsprogramme wieder geschlossen sind. Wenn man den NetworkManager von Hand killt, dann kann sicher manches Ungedeih passieren. Ähnlich wird es sein, wenn der Shutdown-Vorgang nach Ablauf des Timeout dann doch noch forciert wird, was ja Standard ist.
Das weiß ich nicht. Doch ich glaube es kaum, sonst hätten sich auch Andere nicht so viel Mühe mit dem Problem gemacht. Ein Dass das Problem schon so lange "herumgeistert" ohne eine dauerhafte, bequeme und zugleich sichere Lösung zu finden, zeigt zumindest, dass dies alles nicht so einfach ist (siehe dazu auch 211631 und seine vielen Duplikate). Am sichersten ist halt nach wie vor, wenn man zuerst alle kritischen Anwendungsprogramme von Hand schließt, dann die Freigaben ebenfalls von Hand aushängt und erst zum Schluss das System herunterfährt. Die beiden letzten Punkte erledigt Dein Skript, aber eben leider nicht den ersten. Ich weiß nicht, wie das ganz anders strukturierte GVFS das Problem löst, und wie sicher bzw. unsicher die dortige Lösung ist. Gruß – Max-Ulrich |
||||||||||
Anmeldungsdatum: Beiträge: 30 Wohnort: In der Nähe vom Mond |
Ich konnte das Problem auf dem Laptop mit XUbuntu 16.04 mittlerweile lösen. In die Datei rc.local unter /etc/ habe ich folgendes (vor dem Exit!) eingefügt: sleep 30 && mount -a Einträge in der fstab sehen bei mir so aus: //192.168.1.123/homes/wurstwasser /media/Wurstwasser cifs uid=1000,gid=1000,credentials=/home/wurstwasser/.credentials/nas,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm 0 0 Die Netzlaufwerke werden wieder wie gewohnt eingehangen. |
||||||||||
Anmeldungsdatum: Beiträge: 7990 |
Hallo Acer54, In ArchWiki (ArchLinux verwendet ja schon lange systemd) habe ich ein interessantes Workaround gefunden, das bei mir klappt, und bei dem ich bislang keine Sicherheits-Probleme sehe (?). Bitte untersuche doch einmal, ob es auch bei Dir die Probleme behebt. Es genügt, eine Datei /lib/systemd/system/auto_share.service anzulegen mit folgendem Inhalt: After=NetworkManager-wait-online.service Before=systemd-user-sessions.service Dann muss einmalig mit Root-Rechten in einem Terminal folgende Befehlsfolge ausgeführt werden: systemctl enable NetworkManager-wait-online systemctl reenable auto_share.service Nach dieser Prozedur klappt bei mir das Booten und der Shutdown auch bei gemounteten Netzwerk-Shares (auch Samba-cifs) einwandfrei. Auch nach einem Neustart klappt wieder alles – ohne erneutes Ausführen der o.g. Prozedur. Ich bin gespannt. Gruß – Max-Ulrich |
||||||||||
Anmeldungsdatum: Beiträge: 700 Wohnort: Bayern |
Hallo Max-Ulrich_Farber, leider führt das von dir beschriebene Vorgehen zum gleichen negativen Ergebnis beim Herunterfahren... Allerdings verstehe ich nicht, was dieser Service genau tut. Für mich macht es den Anschein als ob dieser "nichts" zwischen dem Vorhandensein der ersten Netzwerkverbindung und der Anmeldung des Benutzers zu tun. Kannst du etwas detailierter Beschreiben, was du wie gemacht hast ? PS.: Ich habe auch das File nicht in /lib/systemd... abgelegt, da dieses nicht existiert. Ich habe es stattdessen unter /etc/systemd/system platziert. Kann das vielleicht die Ursache sein? |
||||||||||
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
|||||||||||
Anmeldungsdatum: Beiträge: 700 Wohnort: Bayern |
Hi Seahawk, habe das anscheinend irgendwie verpeilt. Ich hätte schwören können ich hatte kein /lib/systemd/system als ich letztens das o.g. Vorgehen versucht habe 😬 Mittleiweile habe ichs gefunden 🙄 Allerdings führt die Datei auch an diesem Ort zum gleichen Ergebnis (Shutdown bleibt hängen...) |
||||||||||
Anmeldungsdatum: Beiträge: 7990 |
Und ich hatte bereits angefangen, mir eine Erklärung zurecht zu legen, wie das Workaround funktioniert... ☹ Ich weiß leider gar nicht, wie bei systemd die Shutdown-Sequenz aufgebaut wird. Bei init war das ja noch ganz einfach gewesen: schlichtweg die (damals starre) Boot-Sequenz rückwärts. Ich habe mir nun gedacht, dass systemd beim Booten die Start-Reihenfolge der Dienste notiert, und dann diese beim Shutdown rückwärts durchläuft (?). Dann würde es ja genügen, dafür zu sorgen, dass die Mount-Befehle ganz sicher erst nach dem Aufbau der Netzwerk-Verbindung ausgeführt werden. Dann müsste beim Shutdown das Aushängen vor dem Lösen der Netzwerk-Verbindung geschehen, und alles wäre ok. Und dies sollte ja das Workaround bewirken. War wohl nichts – oder doch? Ist vielleicht nur das Timeout bei NetworkManager-wait-online.service zu kurz eingestellt? Ich mag jetzt damit nicht mehr allzu viel Zeit totschlagen. Im Moment geht ja das Workaround, aber wer weiß, wie sicher und wie lange. – Ich mounte dann halt einfach meine cifs-Freigaben über gvfs-mount und richte einen bequemen Symlink auf den (komplizierten) Mountpunkt in /run/user/1000/gvfs ein. Mit NFS geht das jedoch leider nicht. ☹ |
||||||||||
Anmeldungsdatum: Beiträge: Zähle... |
Nach Update von 14.04 auf 16.04 hing mein Rechner beim Booten auch ewig beim mounten von den NFS Shares. Habe dann nach einer Anleitung im Web die fstab editiert von:
nach
Seitdem klappt das wieder gut beim hoch und runter fahren. |
||||||||||
Anmeldungsdatum: Beiträge: 700 Wohnort: Bayern |
Da ich bei 16.04 leider (trotz div. workarounds) immer wieder die Verzögerung beim Herunterfahren mit gemounteten Cifs habe, (was mittlerweile einfach nur noch nervt) habe ich vor ein paar Tagen umgestellt auf gvfs-mount über das GUI Frontend Gigolo (was eine schöne "Automount" Funktionalität mitbringt) und mounte mein NAS nun mittels SMB. Einige Kopfstände hat es zwar noch benötigt, um das ein oder andere zum Laufen zu bekommen, aber im Großen und Ganzen bin ich zufrieden, auch wenn mir das Einhängen über die fstab und mountscript deutlich besser gefallen hätte, da ich mir dort die "Intelligenz" selbst zurechtlegen und basteln konnte... Nichts desto trotz war es kein Dauerzustand regelmäßig minutenlang zu warten bis der Rechner endlich abschaltet. Solche Bugs (und für mich ist es einer... https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1577885) sind in einer LTS natürlich der Showstopper, die verhindern, dass ich 16.04 auf mein Hauptsystem lasse. Dort läuft immer noch ein sehr stabiles 14.04. |