Celica hat geschrieben:Da wird von einem Bug gesprochen und ein Workaround über ein Script realisiert. Ich verstehe es halt nur nicht, da ja alles wunderbar funktioniert. Wie gesagt: Ich möchte es richtig machen und vor alles verstehen.
Dein Problem ist, dass Dir momentan noch die Erfahrung fehlt, zwischen Alt und Neu zu unterscheiden. Und deswegen tappst Du in die Falle, alten HowTo's oder Ratschlägen zu folgen, welche solcherart Debian-Probleme lösen, die es heute so unter Systemd gar nicht mehr gibt. Das perfide ist, dass diese alten Lösungen zum Teil dann doch wieder zu aktuellen Lösungen werden, weil vorher systemd-Funktionalität so umgebogen wurde, dass systemd wieder sysvinit-Konform ist ... dabei braucht man das gar nicht.
Also.... früher, vor der aktuellen Debian-Version "Jessie" gabs die Version "Wheezy". Der wirklich markante und absolut maßgebliche Unterschied zwischen diesen beiden Versionen begründet sich durch den Wechsel des Start-Systems von sysvinit zu systemd. Das bedeutet, ein früher starrer und linear ablaufender Bootvorgang, der über 100e von speziellen (durch den Laien undurchschaubaren) Wrapper-Scripten in /etc/init.d supportet wurde, die zudem m.E. ziemlich kompliziert in die RunLevel-Dirs gesymlinkt wurden, wurde ersetzt durch einen parallel startenden Bootvorgang, der darauf abzielt,
keine Wrapper-Scripte mehr zu verwenden. Keine Wrapper-Scripte bedeutet, dass in der künftigen Version "Stretch" das Verzeichnis "etc/init.d" so gut wie leer ist.... ich sag dazu "gottseidank!". RedHat-Fedora hat es mittlerweile ganz abgeschafft.... und ich bin sicher, dass Debian das auch tun wird. Mit diesem Schritt ist der gesamte Bootvorgang für mich als Laie bedeutend transparenter und leichter nachvollziehbar geworden.
Soviel als erstes... nun die Mount-Units. Mount-Units sind heute unter systemd obligatorisch. Das bedeutet, jeder Mount wird immer über eine Mount-Unit durchgeführt. Da die fstab aber weiterhin erklärtes und etabliertes Objekt für Mounts bei systemstart ist und bleiben soll, bedarf es eines automatischen Generators, der die fehlenden Mount-Units für die fstab-Einträge erzeugt, wenn die fstab bearbeitet wird. Das macht systemd automatisch. Diesen Vorgang kann man aber umgehen, in dem man einfach selber eigene und optimal eingestellte Mount-Units einrichtet. Das ist für lokale Laufwerke allerdings nicht notwendig, das funktioniert mit dem AutoGen perfekt. Problematisch ist es aber auf Grund des parallelen Systemstarts evtl. für Netzwerk-Laufwerke. Weil es da passieren kann, dass die fstab-Bearbeitung (wegen der lokalen Laufwerke) vor dem erfolgreichen Start (und der Verbindung) des Netzwerkes erfolgen kann. Das bedeutet evtl., der Mount der NAS-Laufwerke failed. Üblicherweise setzen dann da solcherart Scripts wie bei dem "alt-bug-Ratschlag" an, die zudem auch noch auf den GoodWill eines Network-Managers beruhen und darüberhinaus seiner Willkür über dessen Defnition des Netwerkstatus unterliegen. Das heisst, unterschiedliche Distris = möglicherweise unterschiedliche NetMan-Implementierung = unvorhersagbare Definition des Netzwerkstatus = merkwürdige Probleme beim Mount = Rückgriff auf noch merkwürdigere Lösungsvorschläge.
Gerade was den Network-Manager angeht ist mit einem weiteren Problem zu rechnen, und zwar diesen typischen und auch lange bekannten und sehr ärgerlichen Stop-Job-Effekt bei Remote-Mounts über ein WLAN-Nic.Bis heute unter Jessie kloppt der NM einfach die WLAN-Verbindung weg, in dem er vermutlich planmäßig den Daemon wpasupplicant beendet ... dieser Daemon ist für die WLAN-Verbindung an sich zuständig. Nur besteht da das (auch alte) Problem, dass dann die vorhandenen Mounts nicht mehr unmountet werden können, was systemd minutenlang erfolglos beim Poweroff versucht, um darüber wiederum den Shutdown minutenlang zu blockieren. All das kann man bei den Remote-Mounts einfach vermeiden, in dem man eigene Mount-Units erzeugt, die ggf. nach einer weiteren service-unit starten, welche den gewünschten Server "als verfügbar" markiert. Ganz automatisch ist damit auch das o.g. Shutdown-Problem behoben.
Und als drittes und letztes.... zu Deinem Posting in dem Bind-Problem-Thread. Man muss hier die Perspektiven auf eine bestimmte Ressource unterscheiden. Für den Server ist eine bestimmte Festplatte eine lokale Festplatte, die regulär und völlig problemlos über die fstab gemountet wird und deren Festplattenverzeichnisse darüber hinaus und weitergehend separierend ge'bind'et werden können. Mit diesen Bind's können z.B. Unterverzeichnisse der Festplatte als eigene Mountpoints im Server-Dir /media oder /mnt erstellt werden, die dann wieder als "Remote-Platte" von einem Client-PC gemountet werden können. Also, für den Server ist die Platte eine lokal angeschlossen Platte, für den Client ist es eine Remote-Ressource.... beiden ist gemein, dass -egal wie und wohin- auf jeden Fall Mount-Units bestehen, wenn die Platte/Verzeichnisse gemountet ist.
Mein Fazit:
Wenn es jetzt mit Deinem Rechner läuft, würde ich nix ändern. Du musst nur im Hinterkopf behalten, dass diese Lösung nicht unbedingt genau so stabil läuft, wenn sich Rahmenbedingungen ändern, oder wenn Du z.B. einen 'Raspberry Pi 3' via WLAN einsetzen möchtest, oder einen Laptop/Notebook in einem Raum mit eher schlechterem WLAN-Empfang. Dann würde ich bei der Lösungsfindung definitiv keine alten "Krücken" verwenden, sondern eine eindeutig systemd-orientierte Lösung einrichten.
Wenn noch Fragen sind.... frag einfach noch mal.... aber als RundUmBlick müsste das jetzt eigentlich reichen.....
Hth