Mount mit systemd

  • Anlässich des Threades hier: Mit python Netzwerklaufwerk einbinden

    wollte ich es auch endlich in Angriff nehmen und meine Mounts von systemd erledigen lassen. Leider stoße ich auf selbiges Problem wie sich im oben genannten Post zu ende heraus kristalisiert hat.

    Führe ich die Service Unit mit systemctl start ... aus so ist die Einbindung erfolgreich, jedoch nicht bei einem Neustart.

    Nach Änderungen an Service Units wurde auch immer ein: systemctl daemon-reload ausgeführt.

    Service Unit:

    Du Umsetzung versuchte ich anhand des Wiki Eintrages.

    Bei der automatischen Ausführung erhalte ich folgende Fehlermeldung:

    Was mir auch nocht nicht ganz bewusst ist, aber auch hier habe ich schon beide Möglichkeiten probiert, noisefloor schreibt hier von Requires=network_online.target weiter oben von Requires=network-online.target

    Eine Ausgabe von pi@uvpi:/media $ ls /lib/systemd/system | grep .target | grep network ergibt

    Code
    network-online.target
    network-pre.target
    network.target

    hier gehe ich mal davon aus dass es sich um einen Schreibfehler handelt und nur network-online.target korrekt ist?!

    Ebenfalls hat mich diese Seite mit dem Punkt The [Automount] Section neugierig gemacht, allerdings verstehe ich noch nicht ganz den Zusammenhang von mount und automount? Kann das jemand erklären?

  • Wenn ich es richtig verstanden habe, dann brauchst du eine Mount Section und wenn diese zur Bootzeit gemountet werden soll, die passende Automount Section.

    Zitat

    The [Automount] Section

    This unit allows an associated .mount unit to be automatically mounted at boot. As with the .mount unit, these units must be named after the translated mount point's path.

  • Hast du die Unit aktiviert ?

    sudo systemctl enable NAME.mount

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Hallo,

    was passiert denn, wenn du die Zeile /bin/mount //192.168.178.1/fritzbox/Sicherung/RaspberryPi /media/fritz_nas -o credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,sec=ntlm,vers=1.0 im Terminal ausführst? "Error 32" bedeutet AFAIK, dass eine Mount-Option falsch ist... Bei einige gleichgelagerten Problemen hilft wohl auch, `_netdev` den Optionen hinzuzufügen.

    Die `After=` Direktive für's Netzerrk ist wohl nicht nötig, wie ich inzwischen gelernt habe, weil systemd das für Netzwerklaufwerke automatisch macht, siehe https://www.freedesktop.org/software/syste…temd.mount.html.

    `automount` ist IMHO nicht notwendig, weil du keine "on demand" mounting brauchst, sondern einen permanenten mount.

    Gruß, noisefloor

  • Hast du die Unit aktiviert ?

    sudo systemctl enable NAME.mount

    Ja ist aktiviert, sonst würde auch keine Fehlermeldung nach dem reboot zur Verfügung stehen ;) die Frage habe ich aber auch in dem oben verlinkten Thema den anderen Threadersteller gestellt :lol:

    was passiert denn, wenn du die Zeile ...

    Sowohl das, als auch sudo systemctl start media-fritz_nas.mount hängen das Netzlaufwerk erfolgreich ein.

    Bei einige gleichgelagerten Problemen hilft wohl auch, `_netdev` den Optionen hinzuzufügen.

    Also als Option in der fstab hilft _netdev bei mir nicht, deshalb ja überhaupt der Wunsch der kompletten Umstellung direkt zu systemd hin.


    `automount` ist IMHO nicht notwendig, weil du keine "on demand" mounting brauchst, sondern einen permanenten mount.

    Hierfür hätte ich dafür diesen Schlüssel in [Mount] Abschnitt verantwortlich gemacht?!

    LazyUmount= true gesetzt wird, wird das Dateisystem wieder ausgehängt, sobald es nicht mehr benötigt wird. Standardmäßig ist diese Option abgeschaltet.
  • Führe ich die Service Unit mi

    ja, weil da das Netzwerk verfügbar ist. Mit "after network.target" ist keine Gewähr verbunden, dass das Netzwerk wirklich auch verbunden ist, sondern nur, dass irgendwas für das Netzwerk gestartet wurde... ein Networkmanager, systemd-networkd, networking, was auch immer.... das bedeutet aber nicht, dass das Netz auch schon wirklich verbunden ist oder verbunden wird.... sondern nur, dass Netzwerkkomponenten erfolgreich gestartet wurden. Was diese Prozesse dann tun, ist eine zweite Sache.Durch die Parallelstarts und das frühe Starten von Mounts gibts da eben planmäßig Konflikte... was bedeutet, dass "eigene" manuell erstellte neue Prozesse sich gefälligst selber darum zu kümmern haben, dass die von ihnen selber benötigten Abhängigkeiten auch erfüllt sind.


    Die Lösung steht hier:

    etc/fstab mountet beim start nicht meine nas ordner

    • Offizieller Beitrag

    auch schon wirklich verbunden ist oder verbunden wird.... sondern nur, dass Netzwerkkomponenten erfolgreich gestartet wurden

    was ist dann der Sinn dieser Funktion? Wenn ich ihm schon sage, dass er warten soll und es am Ende egal ist, weil nicht mal definiert ist was da eigentlich passiert, kann man es auch sein lassen - der Effekt ist der gleiche. Dieses System ist einfach nur unglaublich umständlich und unzuverlässig. Wenn es am Ende darauf hinausläuft, dass ich ein Script schreiben muss, welches meine Abhänigkeiten sicherstellt, dann kann das mounten auch direkt in dem Script erfolgen. Der Restlichen 20 (Übertreibung macht Anschaulich) systemd Dateien brauch man dann nicht, denn die tun nichts - ausser darauf zu warten, dass das Script sagt "los gehts".

    Wenn es dieser Scripte nicht bedürfen würde, weil das systemd mit seinem after, before, wait, whatever selber regeln kann, würde ich da sogar einen Vorteil drin sehen. So ist es der gleiche Weg wie bei init, nur mit mehr Dateien - mit schlechterem Output.

  • Mit "after network.target"

    Verwende ich aber nicht ;) sondern: After=network-online.target

    Und lt. Ausgabe dessen:

  • Zeig mal die Ausgabe von

    Code
    systemctl list-dependencies network-online.target

    .... nur um zu sehen, dass ich nicht trotzdem recht habe :evil:

  • Ich habe jetzt als Blitzgedanke IPV6 (weil hier nicht verwendet) komplett über den Eintrag in der cmdline.txt (ipv6.disable=1) abgeschaltet. Und das geht auf Anhieb, die mount unit startet auch beim reboot korrekt. Ich werd verrückt.

  • Mit "after network.target" ist keine Gewähr verbunden, dass das Netzwerk wirklich auch verbunden ist, sondern nur, dass irgendwas für das Netzwerk gestartet wurde... ein Networkmanager, systemd-networkd, networking, was auch immer.... das bedeutet aber nicht, dass das Netz auch schon wirklich verbunden ist oder verbunden wird.... sondern nur, dass Netzwerkkomponenten erfolgreich gestartet wurden. Was diese Prozesse dann tun, ist eine zweite Sache.Durch die Parallelstarts und das frühe Starten von Mounts gibts da eben planmäßig Konflikte... was bedeutet, dass "eigene" manuell erstellte neue Prozesse sich gefälligst selber darum zu kümmern haben, dass die von ihnen selber benötigten Abhängigkeiten auch erfüllt sind.

    Sorry, aber hast Du da mal eine belastbare Quelle für Deine Aussagen?

    Mal ehrlich: die Jungs, die sich das ausgedacht und implementiert haben, sind auch nicht auf der Brennsuppe dahergeschwommen und haben sich da sicher was dabei gedacht, denn genau um die Auflösung dieser Abhängigkeiten untereinander geht es imho bei systemd u.a. doch. Nur weil das parallelisiert wurde, heisst das noch lange nicht, dass die Prozesse nicht untereinander kommunizieren.

    Falls dem wirklich so sein sollte, wie Du schreibst, wäre, wie dbv schon schrieb, das Ganze vollkommen sinnlos.

    Und das kann ich mir beim besten Willen nicht vorstellen ...

    cu,

    -ds-

  • Hatte ich mir gedacht....

    1. Du fragst mit einer systemd-target die alte sysvinit-Netzinitialisierung (ifup) ab.... was natürlich nicht funktionieren kann

    2. Targets sind immer passive Units, die selber nix machen. Sie dienen zur Gruppierung und Festlegung von Reihenfolgen

    3. Wann und ob ein Pull-In dieses Targets erfolgt, entscheidet die Netzwerkmanagement-Software... in Deinem Fall ist das eine, die vor Systemd entwickelt wurde

    Mit dem planmäßigen Ergebnis, dass es nicht funktioniert.

    Darüber hinaus, Du willst warten, bis das Netzwerk "up" ist... bitte teile Deiner Netzwerḱmanangement-Software mit, was genau für Dich "up" bedeutet:

    - Die Netzwerkmanagement-Software ist up

    - die NICs sind up und eine IP-Adresse ist zugewiesen

    - die NICs sind up und eine IP-Adresse ist per DHCP angefordert

    - das Netzwerk ist soweit "up", dass DNS-Server erreichbar sind.

    - es wurde (local/global) eine IPv4 zugewiesen

    - es wurde (local/global) eine IPv6 zugewiesen

    - es wurden (local/global) IPv4 und IPv6 zugewiesen

    - das lokale Netz ist erreichbar

    - das Internet ist erreichbar

    - allen gefundenen NICs ist eine Adresse zugewiesen, unabhängig davon, ob sie überhaupt verwendet werden (WLAN/ETH)

    Ok... soweit sogut... wenn Du nun Ifup klargemacht hast, unter welchen Bedingungen der network-online.target für Dich "erfüllt", ist der Rest dann einfach... :evil:

    Die Lösung hatte ich Dir genannt... mein "serverctl.service" ist nur eine Netzwerkmanagement-Software, die unabhängig von systemd oder sysvinit funktioniert... oder eben mit beiden.... weil sie eben einen eindeutigen Zustand definiert.... den Du derzeit nicht definiert hast. Du kannst die Unit auch einfach ins Target verlinken... dann funktioniert auch networt-online.target.... sollte zumindest so sein... oder -wie ich es bevorzuge- der Einfachheit halber direkt anziehen, wie im genannten Beispiel.....

  • Sorry, aber hast Du da mal eine belastbare Quelle für Deine Aussagen?

    https://www.freedesktop.org/wiki/Software/…/NetworkTarget/

    Ist wirklich alles perfekt durchdacht.... das Problem ist wie immer das Festhalten an alten sysvinit-Funktionen. Schmeiss "/etc/init.d/networking" raus, und schon geht alles bestens.

    um die Auflösung dieser Abhängigkeiten

    Das ist doch alles perfekt gelöst und startet auch perfekt ohne jegliche Konflkte. Die Probleme entstehen doch allein dadurch, dass zur Anfangskonfiguration Veränderungen und neue Abhängigkeiten durch den Anwender geschaffen werden... mit einem Mischmach von alten und neuen Sachen... es wird versucht, für die neuen Sachen eine Abhängigkeit auf alte Sachen zu generieren, wobei der alte Kram gar nix davon weiss. ifup ist doch nur noch ein Kompatibiltitätsmodul, die ganzen alten nettools werden doch imho gar nicht mehr weiterentwickelt. Wie kann man da denn Fehler "systemd" anlasten? Sorry, das geht doch imho gar nicht.

    j.m.2.c.

    Einmal editiert, zuletzt von WinterUnit16246 (10. August 2018 um 16:19)

  • Eben ... dachte ich mir doch. Alles andere hätte mich jetzt auch gewundert.

    Hofei: das mit dem Netzwerk wie von @ThomasL beschrieben macht Sinn ... ich hab' noch was gefunden, bin aber nur kurz drübergeflogen -> https://freedesktop.org/wiki/Software/systemd/Debugging/

    //EDIT: Auch nicht schlecht: -> https://www.freedesktop.org/wiki/Software/…ompatibilities/

    cheers,

    -ds-

  • Hi Hofei,

    was mir gerade noch einfällt: kannst Du nicht eine systemd Unit namens z.B. NAS schreiben und darin feststellen ob der NAS online ist? Evtl. gibt es die Möglichkeit dann auf NAS-online.target zu warten ...

    Ich steck' da leider nicht tief genug drin und das wäre noch ne Baustelle, von denen ich eh schon genug hier habe.

    Aber vielleicht weiss @ThomasL da Rat?

    cu,

    -ds-

  • Aber vielleicht weiss ThomasL da Rat?

    Das ist doch genau die Lösung, die ich auch vorgeschlagen habe... ich habs halt "serverctl" genannt.... man kanns auch "checknas" oder sonst wie nennen. Die Besonderheit ist, es wird mit einer IP asufgerufen, deren Verfügbarkeit geprüft wird..... dabei isses egal, ob das mein Server ist, oder ein NAS oder eine anderes Gerät... hauptsache es antwortet auf den Ping.

    etc/fstab mountet beim start nicht meine nas ordner

    Im Folgeartiikel hatte ich auch noch eine Alternative beschrieben, die es ohne Script macht... wobei ich die optisch nicht so toll, finde.

    Einmal editiert, zuletzt von WinterUnit16246 (10. August 2018 um 21:27)

    • Offizieller Beitrag

    lt. Wie kann man da denn Fehler "systemd" anlasten? Sorry, das geht doch imho gar nicht.

    Warum ist denn das alte Zeug noch im Standardsystem? Wenn systemd das alles übernehmen kann und sollte, ist das Vorhandensein von altem Zeug ja gefährlich. Wenn man bereits so ein System auf dem user loszulassen, muss man doch auch bereit sein das ganze Geraffel, welches das behindern würde, zu entsorgen. Also ist es in dem Fall systemd anzulasten - wenn auch indirekt. Es wurde ein System eingeführt was nicht 100% mit existierenden Systemen harmoniert. Es gab mal Zeiten, da hat das bei Debian was bedeutet.

    Wie würde denn eine Version ohne Altlasten und somit ohne zusätzliches "check-script" aussehen?

Jetzt mitmachen!

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