etc/fstab mountet beim start nicht meine nas ordner

  • Moin!

    Ja, ich bin hier auch öfter ins Stutzen gekommen.

    Systemd macht aus der fstab eine mount.unit. Man kann dann mit systemctl den Status des Mountpoint abfragen.

    ich glaube da liegt noch ein langer Weg vor den Entwicklern.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • etc/fstab mountet beim start nicht meine nas ordner? Schau mal ob du hier fündig wirst!

    • Offizieller Beitrag

    Bernd666 Ich persönlich hätte zwar die andere schmutzige Methode über Cronjob bevorzugt, aber so gehts natürlich auch. ;)

    Systemd macht aus der fstab eine mount.unit

    mount.unit? :shy: Da könntsch auuusrasten!

    dbv Das entspricht dem Zeitgeist haben sie hat noisefloor gesagt. :cool:

  • mount.unit? Da könntsch auuusrasten

    Entspannt Euch... das ist NUUUUR ein virtuelles Objekt, welches sich mit seinen Abhängigkeiten in die Zeitlinie des Systemstarts einreiht, damit es an gleicher Stelle -nur in umgekehrter Reihenfolge- beim Shutdown wieder ordentlich geschlossen werden kann. Natürlich ist systemd für das Problem ursächlich verantwortlich, nur hat das nix mit schlampiger Programmierung zu tun, sondern damit, dass Prozesse beim Boot parallel gestartet werden. Der Effekt tritt dadurch ein, dass die fstab schlichtweg ne alte verdorrte Leiche ist, die noch im Kompatibilitätsmode bearbeitet wird und die durch die Parallelisierung nix vom Start des Netzwerkes mitkriegt und auch nicht darauf wartet.... und leider wird diese (imho überflüssige) fstab auch so bleiben.

    Das Problem ist also nicht systemd als solches, sondern der Umstand der Parallelisierung des Systemstarts. Und das gleiche Problem würde exakt genauso mit jedem anderen parallel startenden Init-System bestehen... schlichtweg deshalb, weil die fstab nix an Abhängigkeiten vorsieht, die dazu passen. Darüber hinaus ist auch mount.cifs noch ein Kandidat, der auch nicht für Parallelisierung gedacht ist... sowas wie tägliche Neustarts mit wechselnden NAS-Mounts, die mal verfügbar sind und mal nicht, plus Wechselmedien gibts in den Systemen, für die Debian ursprünglich mal entwickelt wurde, nicht.

    Darüber hinaus, was jeder im mount-helper für CIFS nachlesen kann, gibt es dort den Parameter _netdev nicht. Der Rückgabewert ist IGNORE. Die Lösung ist total einfach... einfach eine eigene Mount-Unit schreiben, die eine Requires-Abhängigkeit zu einer zweiten Unit bekommt, die auf Verfügbarkeit des Servers wartet... das wars... ist eigentlich Kinderkacke.

    Und wenn man trotzdem unbedingt bei der fstab bleiben will, kann man dort einfach die zuvor genannte Server-Prüf-Unit mit einem requieres-Statement direkt in die fstab schreiben. Das funktioniert absolut zuverlässig. Das funktioniert mit systemd und NAS-Laufwerken insgesamt grandios gut. Die Probleme entstehen allein nur durch krampfhaftes Festhalten an abgelösten sysvinit-Mechanismen. Wenn man daran festhält, muss man akzeptieren, dass das nur in einem generierten Kompatibilitätsmode läuft, der auf nix individuelles eingeht.

    • Offizieller Beitrag

    Hallo ThomasL,

    Natürlich ist systemd für das das Problem ursächlich verantwortlich,

    :thumbup:

    Das Problem ist also nicht systemd als solches, sondern der Umstand der Parallelisierung des Systemstarts.

    Ich denke Parallelisierung des Systemstarts ist der Sinn von systemd?

    einfach eine eigene Mount-Unit

    Da war das Wort schon wieder. :shy:

    Und wenn man trotzdem unbedingt bei der fstab bleiben will, kann man dort einfach die zuvor genannte Server-Prüf-Unit mit einem requieres-Statement direkt in die fstab schreiben.

    In Beitrag #36 zitierte ich das Kompendium. x-systemd.automount,x-systemd.requires=network-online.target wäre das in der fstab keine Lösung oder muss es unbedingt eine eigene Server-Prüf-U... sein?


    BTW: Warst das nicht Du der gefühlt vor etwa einem Jahr schrieb, dass er sich zum Thema systemd nicht mehr äußern wollte oder spielt mir die Forendemenz einen Streich? :conf: Bitte nicht falsch verstehen, es geht mir wirklich nur um die Erinnerung. ;)

  • Moin!

    @ThomasL : In welchen Ordner soll denn die home-pi-nas-photo.mount gepackt werden. Weil eigentlich sieht die mount logischer aus, als die fstab.

    Gruss Bernd

    Aber wir sollten es wenn, im off-topic-Bereich weiter machen.

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Moin!

    So sieht sie aus.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • In Beitrag #36 zitierte ich das Kompendium. x-systemd.automount,x-systemd.requires=network-online.target wäre das in der fstab keine Lösung oder muss es unbedingt eine eigene Server-Prüf-U... sein?

    Nein! Ja! :)

    network-online.target ist kein eindeutig definierter Zustand und irgendwie Distributions- oder Diensteabhängig. Das heisst, irgend ein Dienst zieht dieses Target zu irgendeinem Zeitpunkt an. Heisst das, es wurde angezogen, wenn die NICs initialisiert wurden? Alle? Oder eines? Welches? Oder der NWM wurde gestartet und versucht eine Verbindung zu öffnen? Oder DHCP wurde gestartet und wartet auf eine IP? Oder das die NICs UP sind? Wenn die NICs UP sind, bedeutet das nicht, dass sie eine IP haben. Und wenn sie eine IP haben, bedeutet das nicht, dass ein Ressourcen-Server erreichbar ist. Und wenn der Server erreichbar ist, bedeutet das nicht, dass er sich im gleichen Subnet befindet. Sind alle Netze für alle NICs verbunden?

    Also, wann möchtest Du network-online.target "angezogen" haben? Die Falle ist, selbst wenn die Netzverbindung etabliert ist, also ein Netz verbunden ist, bedeutet das nicht, dass das Netz des NAS verbunden ist. Und wenn das Netz zum NAS verbunden ist, bedeutet das nicht, dass das NAS überhaupt eingeschaltet ist.... und wenn nicht schlägt eben jeder Mount fehl. All das hat aber nix mit systemd zu tun. Debian handhabt eben nicht nur private Mininetze.....

    Warst das nicht Du der gefühlt vor etwa einem Jahr schrieb, dass er sich zum Thema systemd nicht mehr äußern wollte

    Das weiss ich nicht mehr... kann aber gut sein, wenn ich damit "konfliktorientiert" gemeint habe. Es ist völlig sinnlos, einen notorischen Gegner überzeugen zu wollen. Mir geht dabei -passend auch zum Thread- eine Szene durch den Kopf. Stell Dir meinen Nachbar vor, der jeden Morgen rumtobt, weil er täglich sein Auto anschieben muss und flucht dabei aufs Auto und den Hersteller "Dreckskarre, Mistkiste, Scheiss-Opel-VW-Ford-Sonstwer".

    Warum flucht er? Weil er zwei Jahrzehnte sein Auto in der Garage leicht und zuverlässig jeden Morgen mit der Kurbel anwerfen konnte. Aber dieser Dreckshersteller hat ihm jetzt ein Auto hingestellt, was keine Kurbel mehr hat, was er einfach nicht akzeptieren kann und auch nicht will. Aber Gottseidank kann er mit einem vom Hersteller gegebenen Kompatibilitätsmodus den Wagen anschieben... was er auch jeden morgen laut fluchend tut. Wenn ich ihm sage, nimm doch einfach den Schlüssel und lass ihn damit an, guckt er mich völlig verständnislos an, fängt wieder an zu fluchen und schiebt das Auto wieder an. Und abends wirf er mir die Ignoranz des Herstellers vor, der nicht beachtet, das es Leute gibt, die Bergauf anschieben müssen, oder gefährlich Bergab, oder bei Regen, oder bei Schnee... nur weil diese Ar**lö****er die Kurbel weggelassen haben.

    Warum er nicht einfach den Schlüssel nimmt...?... keine Ahnung, ich verstehs nicht, ich habs ihm zwei, dreimal gesagt, aber anscheinend versteht er mich auch nicht. Aber so ist er halt... nun lass ich ihn schieben.

    In welchen Ordner soll denn die home-pi-nas-photo.mount gepackt werden.

    Code
    /etc/systemd/system

    Man erstellt eine Datei?

    Wofür? Für die Mount-Unit? Oder zum Prüfen des NAS, ob der überhaupt erreichbar ist?

    2 Mal editiert, zuletzt von WinterUnit16246 (26. Januar 2018 um 20:39)

  • Bernd, hier ein einfaches Beispiel für einen Mount nach /media/mynas

    Code
    mkdir -p /media/mynas
    nano /etc/systemd/system/media-mynas.mount
    
    systemctl start media-mynas.mount
    systemctl status media-mynas.mount
    systemctl enable media-mynas.mount

    Enable natürlich nur, wenn im Status keine Fehler berichtet sind! Beachten: der Unit-Name MUSS zum Mount-Point passen!.

    Die Mount-Unit.... alle anderen werden entsprechend diesem Muster ebenso angelegt. Die Mount-Parms kann man ja für sich selber anpassen. Unbedingt das Requires-Statement beachten..... damit ist eine absolute Abhängigkeit definiert.

    Jetzt brauchts nur noch eine Unit, die in der Mount-Unit als "requires" zwingend verlangt wird, und ein Miniscript, was den Server prüft:

    Code
    nano /etc/systemd/system/serverctl.service

    Das Script... dessen Service-Unit man pauschal für jede andere Unit verwenden kann, die vom genannten Server abhängig ist.

    Code
    nano /usr/local/bin/serverctl

    Die Serverctl-Unit wird nicht enabled, die wird automatisch durch das requires-Statement angezogen. Nicht vergessen, die Rechte anzupassen, die Units auf root:root 644, das Script auf root:root 755. Im Log kann man sich anschauen, wie lange serverctl gewartet hat, bis der Server verfügbar war..

    journalctl -b | grep thlu

    HTH

    5 Mal editiert, zuletzt von WinterUnit16246 (11. August 2018 um 11:55)

  • Und wem der Weg zu kompliziert ist, ändert in der fstab bei den NAS-Einträgen in den Options von auto einfach auf noauto und enabled dieses Service-Unit. Das funktioniert auch, wenn man unbedingt an der fstab festklebt.

    Code
    nano /etc/systemd/system/chkserver.service
    systemctl start chkserver.service
    systemctl status chkserver.service
    systemctl enable chkserver.service

    Rechte: root:root 644

    Mit einem vorherigem journalctl -f in einem zweiten Terminalfenster sieht man gleich Meldungen, wenn man die Unit von Hand startet.

    Und natürlich muss die IP 192.168.172.35 individuell angepasst werden.

    4 Mal editiert, zuletzt von WinterUnit16246 (26. Januar 2018 um 22:16)

  • Moin Thomas,

    danke für deine Ausführungen!!!

    Ich habe mir mal eine *.mount gebaut. Händisch starten funktioniert. Um es richtig zu machen, sollte man dann noch diese Sache mit serverctl einbauen.

    Aber gut das wir darüber geschrieben haben. Nun ist mir wieder einiges klarer geworden.

    Danke nochmal

    Gruss Bernd

    //EDIT und wenn man das "Warten auf Netzwerk" einschaltet, gehts auch automatisch. Cool!!!!

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

    Einmal editiert, zuletzt von Bernd666 (26. Januar 2018 um 23:02) aus folgendem Grund: Edit angehangen aus 2 " gemacht

  • und wenn man das "Warten auf Netzwerk" einschaltet, gehts auch automatisch.

    Das ist eigentlich die schlechteste Lösung, weil damit in beträchtlichem Maße der Systemboot blockiert wird. Soweit ich mich erinnere, passiert mit dem "warten" nix anderes, als das verhindert wird, dass sich dhcpd wegforkt, was wiederum zur Folge hat, dass alle vom Netz abhängigen Targets und Services nicht gebootet werden. Das mag vielleicht noch auf einem stationären Desktop-PC oder einem PI zufriedenstellend funktionieren, weil irgendwann das Netzwerk verbunden ist, aber als generelle Lösung ist das Mist. Sobald man einen Laptop mit wechselnenden Netzwerkverbindungen hat, ist es besser, ein generelles Handling zu etablieren... einfach deshalb, damit man eine portierbare Lösung für alle Distributionen hat... die auch für den PI gilt. Eine Lösung, die definitiv nicht den Boot pauschal blockiert, sondern nur explizit betroffene Units warten lässt.

    Die Option "Warten aufs Netz" in der raspi-config ist unter systemd imho ein absolutes NoGo und sollte wirklich nur noch bei einem sysvinit-Boot verwendet werden, denn da spielts wohl keine Rolle, weil der Start sowieso seriell abläuft.

    Und das rückst Du erst jetzt raus?

    Nee, das muss bald 2 Jahre her sein, dass ich das hier schon genau so beschrieben habe, sogar mehrfach. Ich garantiere Dir, in einem Jahr (oder weniger) wird der nächste das gleiche Problem haben und wieder werden sich altgeschulte Linuxer an _netdev versuchen, obwohl es den Parameter in man mount.cifs gar nicht gibt und fragen "mount-unit? häh?" ... und das im dritten Jahr "systemd" seit Jessie. Und warum soll ich mich reinhängen, wenn sich 3 Fachleute schon hier tummeln. Da gehe ich einfach davon aus, dass das gelöst wird. Ich war nur neugierig, warum das hier 3 Seiten dauert und bin dann wegen der anscheinenden Irritation/Verblüffung über eine mount-unit wach geworden.

    • Offizieller Beitrag

    @ThomasL

    Danke für dieses praxisnahe Beispiel

    der Unit-Name MUSS zum Mount-Point passen!.

    eek. Das ist ja hochgradig sinnlos....ähm einschränkend. Gibt's da noch weitere Restriktionen? du hast media-nas verwendet, kann es auch media.nas oder medianas sein?

    Man kann aus nem fstab eintrag auch ne Wissenschaft machen ;)

  • Das ist ja hochgradig sinnlos....ähm einschränkend


    Ich halte das nicht für sinnlos, ganz im Gegenteil.....weils sich einerseits in der Namenskonvention für die autogenerated Units befindet. Und andererseits ist es damit total einfach, eine Unit beim Shutdown oder bei einer Userabmeldung namentlich zu benennen, in dem man einfach die Mount-Points in /proc/mounts auswertet, ohne vorher zu wissen, welche Units es gibt, ob die aktiv sind oder nicht, und wie die Unit für einen bestimmten Mount-Point heisst. Darüber ist es dann total easy, eine zu einem aktiven Mount-Point gehörende Unit zu ermitteln. Gäbe es da nicht diese Restriktion, wüsstest Du nicht, mit welcher Unit dieser Mount-Point erstellt wurde. Aber so kann man alles generisch abhandeln, ohne sich eigene Tabellen zum Nachlesen anlegen zu müssen und ohne sich zu merken, welche Mounts habe ich bei systemstart überhaupt geöffnet. Das ist beispielsweise dann wichtig, wenn man userbezogene Mounts hat.... die je nach Anmeldung wechseln.

    Mount-Point: /media/SSD = Unit: media-SSD.mount

    Mount-Point: /mnt/HD = Unit: mnt-HD.mount

    Mount-Point: /media/Filme = Unit: media-Filme.mount

    Ich würde das auch nicht so kompliziert mit den Mount-Points machen... so bescheuerte Name (sorry) wie oben, würde ich nicht nehmen. Stattdessen lieber kurz und knackig und ausdrucksstark. Ich finde das jedenfalls total klasse, wie es ist und empfinde das als wirklich durchdacht gelöst.

    Mein lieber DBV, Du bist so ein großer Fachmann... überwinde doch endlich Deine Abneigung gegen systemd... das ist wirklich klasse und steckt dieses armselige sysvinit dreimal in den Sack.... :)

  • werden sich altgeschulte Linuxer an _netdev versuchen, obwohl es den Parameter in man mount.cifs gar nicht gibt

    Nur so:

    man mount unter FILESYSTEM INDEPENDENT MOUNT OPTIONS

    Nein, dies soll kein Anreiz für eine systemd/fstab pro-/contra-Diskussion sein, nur ein (historischer) Hinweis.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Nein, dies soll kein Anreiz für eine systemd/fstab pro-/contra-Diskussion sein, nur ein (historischer) Hinweis.

    Genau das ist es... ein HISTORISCHER Hinweis, nix mehr, nix weniger... und hier, wie man im Vorposting sieht, nicht hilfreich, sondern nur wieder neue Verwirrung stiftend.

    Soll heissen das _netdev übergeordnet existiert und somit funktioniert?

    Nein, das solls nicht heissen... sondern das, was Lutz geschrieben hat... es ist nur ein historischer Hinweis. Es besteht unter systemd KEIN Unterschied, ob _netdev eingetragen ist oder nicht. systemd verwendet vor dem Mount einen FS-Prober, mit dem es sowieso feststellt, dass CIFS (und einige andere) Netzwerk-FS sind, und dann ist es völlig egal, ob da _netdev steht oder nicht. Darüber hinaus wird sowieso ein spezieller Mount-Helper aufgerufen, hier mount.cifs... und wie gesagt, auch da hat _netdev keine Auswirkung.

    Wer sich dafür interessiert, kann das nachsehen im systemd-Git-Repo unter systemd/src/core/mount.c -> mount_needs_network() und systemd/src/basic/mount-util.c -> fstype_is_network().

    Was passiert stattdessen, wenn es sich um ein Netzwerk-FS handelt? Der Mount wird einfach nur nach "hinter" network-online.target geschoben, was aber gar nix mit einem verfügbaren Netzwerk zu tun hat und es wird auch nicht aufs Netzwerk gewartet. Man kann sich das auf einfachste Weise Weise selber ansehen und davon überzeugen, dass nicht gewartet wird, sowohl in der Unit selber und als auch im Boot-Plot. Ich hatte hier die Maschine ohne Netzwerk gestartet. Das rennt mit oder ohne Netzwerk gleichermaßen durch.

    Boot-Plot

    3 Mal editiert, zuletzt von WinterUnit16246 (27. Januar 2018 um 21:22)

  • Hallo Thomas,

    ich beziehe mich auf Post #50:

    Ich habe das mal Versucht da ich folgendes Problem habe:

    Probleme mit Mounting eines NAS via FSTAB

    Ich habe also die Datei "chkserver.service" angelegt und sie mit dem Inhalt darunter gefüllt, Ip Adresse habe ich entsprechend meines NAS angepasst.

    Chmod habe ich auch gemacht. Danach habe ich den ersten der drei befehle ausgeführt und nach einigem warten bekam ich eine fehlermeldung im Journal in er anderen Konsole zurück:

    Code
    Jan 27 23:47:29 raspberrypi systemd[1]: Starting Mount if NAS is reachable...
    Jan 27 23:48:09 raspberrypi systemd[1]: chkserver.service: Main process exited, code=exited, status=1/FAILURE
    Jan 27 23:48:09 raspberrypi systemd[1]: Failed to start Mount if NAS is reachable.
    Jan 27 23:48:09 raspberrypi systemd[1]: chkserver.service: Unit entered failed state.
    Jan 27 23:48:09 raspberrypi systemd[1]: chkserver.service: Failed with result 'exit-code'.
    Jan 27 23:48:09 raspberrypi sudo[22180]: pam_unix(sudo:session): session closed for user root
    Jan 27 23:49:38 raspberrypi sudo[22344]:       pi : TTY=pts/0 ; PWD=/etc/systemd/system ; USER=root ; COMMAND=/bin/nano chkserver.service
    Jan 27 23:49:38 raspberrypi sudo[22344]: pam_unix(sudo:session): session opened for user root by pi(uid=0)

    Habe das auch nochmal mit DNS Name statt IP probiert - keine Änderung.

    Man muss dazu sagen, dass der Server definitiv läuft, meien frau schaut grad n Film darüber, ping aus dem terminal klappt auch.

    Was macht der Nils falsch?

    Gruß

    der Nils

  • Moin Jevermeister,

    du hast die Datei anscheinend in das richtige Verzeichnis gelegt, aber sie wird nicht gestartet.

    Ich habe mir eben auch die chkserver.service erstellt. Bei mir geht es, aber das tröstet dich sicher nicht ;-))

    Die Fehlermeldung sagt aus, das er die serviceunit nicht starten kann.

    Bei mir sieht es so aus.

    Code
    ls -l /etc/systemd/system/chkserver.service 
    -rw-r--r-- 1 root root 381 Jan 28 01:21 /etc/systemd/system/chkserver.service


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!