Mount mit systemd

  • Warum ist denn das alte Zeug noch im Standardsystem?

    Ganz einfach deshalb, damit man sich auch ein Debian ohne systemd erstellen kann. Ich persönlich halte das allerdings für eine grandiose Fehlentscheidung ... wie zum Beispiel auch rsyslog beizubehalten, oder ntp, oder sudo, oder die net-tools, oder networking....da gibts noch mehr. Tja, das muss einem aber klar sein, die Revolte der "alteingesessenen" hätte astronomische Ausmasse angenommen, wenn man den ganzen alten Kram -für mich sind das alles Leichen- auf einmal rausgefeuert hätte. Frag Dich mal nach Deiner Stimmung, wenn das alles mit Jessie rausgeflogen wäre....

    Und ja, ich gebe zu, systemd ist kompliziert, und es wird oft abgelehnt, weils eben kompliziert ist, weils rigoros alte paradigmen über Board geworfen hat, alte Zöpfe abgeschnitten hat... es erfordert ein komplett neues Denken. Und aufgrund der Tatsache, dass alles parallel ablaufen kann und die frühere wohlige Ordnung strenger Serialität hinter sich gelassen, sind viele Leute einfach überfordert. "Warum muss man alles ändern...?... es war doch alles gut"... Meine Antwort darauf ist "Das bessere ist des guten Feind". Fakt ist, ich habe mit systemd Möglichkeiten, die weit über das total limitierte sysvinit hinweg hinaus gehen.

    Unter sysvinit hatte man eine lineare Ordnung, die man recht einfach logisch nachvollziehen konnte. systemd konfrontiert einen hingegen mit einer Komplexität, die nicht so leicht nachvollziehbar ist... man muss sich da intensiv einarbeiten... die Wege verstehen, die Zusammenhänge, die Ziele, das Vorgehen. Erst dann merkt man, wie genial das ist. Der Konzept an sich ist genial, bedauerlicherweise ist es die Umsetzung nicht. Viele Probleme basieren aber leider eben darauf, dass systemd versucht hat oder versuchen musste, die Kompatilbität zu früher zu gewährleisten.... und dabei zu viele alte Leichen mit Zwangsbeatmung am Leben halten musste. Es mussten zu viele Interessen am Alten festhaltender Leute und zu viele alte laufende (wichtige) Systeme beachtet werden. Ich glaube aber, es wird immer besser, es braucht nur noch ein bisschen... so wie jede gute neue Entwicklung.

    Und für mich ist ein Fakt, es wird auch in Zukunft weiter noch komplizierter werden... davon bin ich überzeugt... und genau das nennt man Fortschritt. Irgendwann werden KI-Elemente Einzug halten, oder gerätelose Interaktion.... was beides dann die nächste große Eskalationsstufe beinhaltet... denn auch das muss dann eingestellt und in Betrieb genommen werden.

    Meiner Meinung nach sind wir die Win95-Generation... und damit kurz vorm Aussterben.... *lol*... wir sind so ein bisschen, wie die Pferdewagen-Kutscher vor 100 Jahren, die sich über die neue Konkurrenz der stinkenden Knatterkisten aufregen.... und nicht verstehen, dass denen die Zukunft gehört... was die Geschichte letztlich bewiesen hat.

    3 Mal editiert, zuletzt von WinterUnit16246 (10. August 2018 um 22:46)

  • Hi @ThomasL,

    Ganz einfach deshalb, damit man sich auch ein Debian ohne systemd erstellen kann.

    da möchte ich noch mal auf die Frage von dbv zurückkommen:

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

    sprich: gibt es eine einfache Möglichkeit sich ein rein auf systemd basierendes Raspbian-System zu bauen, das erst mal keinerlei tiefere Kenntnisse voraussetzt?

    Das wäre nämlich dann genial, um sich damit mal auseinanderzusetzen ... ohne störende Einflüsse durch, wie Du sie nennst "zwangsbeatmete Leichen" ...

    Würd' mich jetzt auch interessieren.

    btw: das wäre wahrscheinlich auch für Hofei ganz nützlich.

    cheers,

    -ds-

  • Der Hofei ist jetzt dann soweit dass ich das in Betrieb nehme:

    Der Grund für die geplante Umstellung von fstab auf systemd war, dass das system es sich selbst verwaltet, wann die Einbindung erfolgen soll.

    Jetzt stellt sich aber heraus dass Raspbian / bzw. Debian noch nicht mal in der Lage ist, Boardmittel auszuliefern für systemd die Selbstständig dafür in der Lage sind das zu Organisieren, dann hilft mir auch das mount "Zeugs" von systemd nichts.:thumbdown:Wenn ich wieder ein eigen selbst erstelltes Skript brauche das auf gut Glück pingt, dann geht das obere Python Skript auch und erfordert keine Umstellung auf Systemd. Wovon ich zuvor echt nicht abgeneigt gewesen bin.

    Aktuell ist es so, dass ich weder mit den Service Units von STF zum Erfolg kam, als auch nicht mit dem verlinkten Thread von @ThomasL, wo ich die Lösung versucht hätte zu umsetzen wo nicht das zusätzliche bash Skript benötigt wird.

    Wie man vielleicht erkennen kann, bin ich von dem Thema gerade etwas genervt - Sorry dafür 

  • sprich: gibt es eine einfache Möglichkeit sich ein rein auf systemd basierendes Raspbian-System zu bauen, das erst mal keinerlei tiefere Kenntnisse voraussetzt?

    Nein, ich glaube nicht, dass es das gibt. Wenn es insgesamt komplizierter geworden ist, gibts keinen Weg, wie man an dieser Kompliziertheit dran vorbei kommt. Ich sag, man muss es einfach machen und das alte loslassen.... auf meinen systemen ist das immer der erste Befehl: apt purge sudo rsyslog, ntp, dhcpd Und dann richte ich das über systemd ein, was ich brauche.

    Ich habe mir damals einen Haufen Test-Units für alle Unit-Types geschrieben und mit einfachen Log-Scripten (single oder endlos) getestet und versucht die Unterschiede zu verstehen.... warum forking darauf setzt, dass sich der Prozess selber forkt, simple aber nicht.... was oneshot ist und wann man den braucht.... was targets sind, usw.... das geht aber nur, wenn man mit Spass am Experiementieren einfach die Zeit opfert. Und dann fragen, wenns nicht mehr weitergeht, wie jetzt hier im Thread. Es ist unzweifelhaft Arbeit, an der man nicht vorbeikommt, wenn man es verstehen will. Und Du kannst drauf vertrauen, wenn Du systemd intus hast, wird das nächste kommen, was einen wieder vor die Herausforderung alles neu zu lernen stellen wird.

    j.m.2.c.

  • :dau1:

    So und ich hab in der Zwischenzeit noch den Lösungsvorschlag mit dem zusätzlichen Skript versucht - und wieder gescheitert - :rip:

    Aktueller Stand:

    Pfad zum Einhängen: /media/fritz_nas

    Passende Service Unit: cat media-fritz_nas.mount

    serverctl.service:

    und dein Skript...welches funktionieren müsste, denn journalctl -b | grep thlu ergibt:

    Code
    Aug 10 23:00:57 uvpi thlu:serverctl[361]: active/running   Server=192.168.178.1
    Aug 10 23:01:05 uvpi thlu:serverctl[949]: Host 192.168.178.1 is reachable! (RC:0, after 8 Seconds wait)
    Aug 10 23:01:05 uvpi thlu:serverctl[952]: Successful terminated with exitcode=0

    Jedoch für die Mount Unit bekomme ich folgende Fehlermeldung:

    wohingegen ein manuelles systemctl start media-fritz_nas.mount zum Erfolg führt:

    Code
    ● media-fritz_nas.mount - Mount der fritz_nas
       Loaded: loaded (/etc/systemd/system/media-fritz_nas.mount; enabled; vendor pr
       Active: active (mounted) since Fri 2018-08-10 23:08:25 CEST; 3s ago
        Where: /media/fritz_nas
         What: //192.168.178.1/fritzbox/Sicherung/RaspberryPi
      Process: 1210 ExecMount=/bin/mount //192.168.178.1/fritzbox/Sicherung/Raspberr
       CGroup: /system.slice/media-fritz_nas.mount
    
    Aug 10 23:08:25 uvpi systemd[1]: Mounting Mount der fritz_nas...
    Aug 10 23:08:25 uvpi systemd[1]: Mounted Mount der fritz_nas.

    :?:

  • Wenn ich wieder ein eigen selbst erstelltes Skript brauche das auf gut Glück pingt, dann geht das obere Python Skript auch und erfordert keine Umstellung auf Systemd

    Du hast trotzdem die Umstellung auf systemd... das darfst Du nicht vergessen, denn die fstab mountet heute nicht mehr, die fstab ist quasi tot.... Punkt! Es werden heute für die fstab-Einträge über einen fstab-Generator generische virtuelle Mount-Units erzeugt.... einfach aus dem Grund, damit sich die Mounts zur Sicherstellung der Abhängigkeiten in umgekehrter Reihenfolge für den umount in den Shutdown einreihen können. Im Grundegenommen hälst Du damit einen zusätzlichen -aber imho unnötigen- Prozess während des Bootens am Leben. Das ist natürlich nix schlimmes, aber es ist eben so.

    Nun wäre es interessant zu erfahren, warum Deine Versuche erfolglos waren.... an den Units oder am Script liegts nicht..... da wird irgendein Fehler bei der Übertragung passiert sein.

  • Das ist schade, dass man sich z.B. über die packaging-tools ohne grossen Aufwand da nicht selbst eine Art "systemd-only" Distri basteln kann. Ich kann mir gut vorstellen, dass das auch für eine breitere Akzeptanz sorgen würde.

    Aber so lange so ein Misch-masch unterwegs ist, werden die Leute - für mich aus durchaus verständlichen Gründen - systemd ablehnen ( siehe Hofei ;) ).

    Naja ... dann harren wir mal der Dinge die da kommen ...

    Aber danke @ThomasL für Deine Einschätzung.

    cu,

    -ds-

  • Das ist ja echt verrückt.... Du hast aber nicht das requires-Statement auf die serverctl.service in der Mount-Unit vergessen?

    Mach bitte mal folgendes....

    systemctl stop media-fritz_nas.mount

    Kontrollieren, ob der Mount wirklich getrennt ist.

    df

    Dann ein Vollbild-Terminalfenster öffnen:

    journalctl -f

    Und dann in einem zweiten verkleinerten Terminalfenster

    systemclt start media-fritz_nas.mount

    Wenn dieser Mount dann fehlerfrei durchgeführt wird und das Script den Server als verfügbar anzeigt (beides im journal-Terminal), sollte der Mount auch bem nöchsten Systemstart erfolgreich sein.

    Sofern er aktiviert wurde:

    systemctl enable media-fritz_nas.mount

  • systemd ablehnen ( siehe Hofei ;) ).

    Nein nein, ich lehn das ganze nicht prinzipiell ab, meine 24/7 Python Projekte lasse ich mittlerweile alle von systemd starten und überwachen, auch hab ich die ganzen logging Funktionen in Python so umgebaut, dass diese wenn von systemd automatisch gestartet worden sind mit dem Journal Logger von systemd kommunizieren.

    Aber das mit dem mount gerade :elektro:


    Du hast trotzdem die Umstellung auf systemd... das darfst Du nicht vergessen, denn die fstab mountet heute nicht mehr, die fstab ist quasi tot.... Punkt!

    Darüber hatte ich gestern auch gelesen, bei der Suche nach weiteren Informationen, gemeint war das auch mehr so, dass ich mir dann die Arbeit nicht antun muss die bestehenden fstab Einträge zu entfernen, neue mount Units bei systemd anzulegen etc. wenn ich eh pingen muss, und dann kann man ja auch noch ein mount -a ausführen - so wars gemeint.

    Wo der Fehler ist....kA ich wüsst jetzt nicht mehr wo ich ansetzen soll :dau2:

  • Das ist ja echt verrückt.... mach bitte mal folgendes....

    Oja, ich weiß....ich werd langsam verrückt :lol:

    Nun ja was soll ich sagen....

    ergibt >>

    Neustart:

  • Wo der Fehler ist....kA ich wüsst jetzt nicht mehr wo ich ansetzen soll

    Du hast aber nicht das requires-Statement auf die serverctl.service in der Mount-Unit vergessen?

    Zeig noch mal die aktuelle Mount-Unit... die bei systemstart failed.

  • "Leider" nein:

    auch ein systemctl daemon-reload wurde nach jeder Änderung durchgeführt^^

  • Nein nein, ich lehn das ganze nicht prinzipiell ab, meine 24/7 Python Projekte

    da hast Du micht falsch verstanden ... ich meinte damit, dass es den Leuten imho unnötig schwer gemacht wird (nicht jeder hat eine so hohe Frustrations-Toleranz-Schwelle wie Du) und es dadurch genügend Gründe gibt, systemd abzulehnen.

    //EDIT: so was, nur andersrum, wäre halt super -> https://wiki.debian.org/systemd#Installing_without_systemd

    Aber gut, lassen wir das :(

    cu,

    -ds-

  • Oja, ich weiß....ich werd langsam verrückt

    Ich jetzt auch.... :wallbash: ... und bin völlig irritiert.... ich kann den Fehler reproduzieren.... was ist denn das für ein Mist....?

    Code
    # journalctl -b | grep -i "serverctl\|fritz"
    Aug 11 11:01:45 thomaspc systemd[1]: Starting thlu:serverctl.service:   Waiting for Network or Server to be up...
    Aug 11 11:01:45 thomaspc systemd[1]: Mounting thlu:Mount der fritz_nas...
    Aug 11 11:01:45 thomaspc thlu:serverctl[2115]: active/running   Server=172.1.1.2
    Aug 11 11:01:45 thomaspc systemd[1]: media-fritz_nas.mount: Mount process exited, code=exited status=32
    Aug 11 11:01:45 thomaspc systemd[1]: Failed to mount thlu:Mount der fritz_nas.
    Aug 11 11:01:45 thomaspc systemd[1]: media-fritz_nas.mount: Unit entered failed state.
    Aug 11 11:01:50 thomaspc thlu:serverctl[2636]: Host 172.1.1.2 is reachable! (RC:0, after 5 Seconds wait)
    Aug 11 11:01:50 thomaspc thlu:serverctl[2639]: Successful terminated with exitcode=0
    Aug 11 11:01:50 thomaspc systemd[1]: Started thlu:serverctl.service:   Waiting for Network or Server to be up.

    Der Mount-Versuch passiert anscheinend, bevor Serverctl zurückkommt.... das muss ich jetzt mal eben austesten... immer wieder was neues......

  • Sowas verrücktes... und dabei muss man nur die Man-Page lesen.... :saint:

    Jetzt gehts:

    Code
    # journalctl -b | grep -i "serverctl\|fritz"
    Aug 11 11:48:25 thomaspc systemd[1]: Starting thlu:serverctl@172.1.1.1.service:   Waiting for Device 172.1.1.1 to be up...
    Aug 11 11:48:25 thomaspc thlu:serverctl[2062]: active/running   Server=172.1.1.1
    Aug 11 11:48:29 thomaspc thlu:serverctl[2342]: Host 172.1.1.1 is reachable! (RC:0, after 4 Seconds wait)
    Aug 11 11:48:29 thomaspc thlu:serverctl[2352]: Successful terminated with exitcode=0
    Aug 11 11:48:29 thomaspc systemd[1]: Started thlu:serverctl@172.1.1.1.service:   Waiting for Device 172.1.1.1 to be up.
    Aug 11 11:48:29 thomaspc systemd[1]: Mounting thlu:Mount der fritz_nas...
    Aug 11 11:48:30 thomaspc systemd[1]: Mounted thlu:Mount der fritz_nas.

    Die Lösung war ein einfaches "after-Statement" in die Unit einzusetzen.... ich habe das Modul angepasst.... siehe:

    etc/fstab mountet beim start nicht meine nas ordner

    Bitte nicht durch die Ausgabe mit serverctl@172.1.1.1.service irritieren lassen. Das hat damit zu tun, weil die originale serverctl.service eine explizite Server-Angabe enthält, ich aber hier eine instantiierte verwendet habe. Das war hier notwendig, weil eben Samba-Server und Fritz-NAS unterschiedliche Server sind und somit unterschiedliche IPs haben... und meine anderen Mounts warte auf einen andere IP. Durch die Instantiierung hatte ich die notwendige Flexibilität.... was aber für das Problem hier keine Auswirkung hat. Hier kommts anscheinend nur auf das After-Statement an.

  • Nachtrag.....

    Options=credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,sec=ntlm,vers=1.0

    Ich würde eine Änderung versuchen.... weniger zwingend vorgeben, mehr die Defaults arbeiten lassen,das verhindert imho künftige Fehler:

    Options=credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,rw

    Bei meiner 7490 gehts ohne den sec-Parameter. Wenn es allerdings nicht anders geht, dann natürlich lassen...... :conf:

  • Also vers=1.0 muss ich lassen, neuere Versionen unterstützt AVM noch nicht :notfunny: auch das neu kommende OS fritz 7 nicht.
    sec=ntlm weiß ich nicht mehr warum das drin ist, werd ich mal rausnehmen.

    :danke_ATDE:Für deine Unterstützung und das du dir die Zeit genommen hast mein Problem zu reproduzieren. Mit dieser oben genannten Änderung funktioniert es nun! :)

    Eine Bitte hätte ich dann doch noch an dich, da man im Internet (zumindest ich) bisher noch keine Funktionierende Lösungen findet wie man das ganze schnell und einfach zum Laufen bekommt, würde ich es super finden, wenn du hier Tutorials & Anleitungen ,

    ein Tutorial/Anleitung verfasst wie man eine Service Unit zum Mounten von Netzwerklaufwerken erstellt. Würde es nicht fair finden wenn ich dazu eine Anleitung schreibe, wenn du doch die ganze Vorarbeit geleistet hast ;)

  • Hab zu der ganzen Thematik jetzt nochmals eine Frage:

    Nachdem das Netzlaufwerk erfolgreich gemountet worden ist, habe ich die Fritzbox vom Strom getrennt, 10 Minuten gewartet und wieder eingesteckt.

    Das Netzlaufwerk war danach immer noch erfolgreich gemountet (Netzlaufwerk ist direkt die NAS von der Fritzbox (FritzNAS))

    Wer oder was ist dafür zuständig, dass nach einem Verbindungsverlust wieder automatisch gemountet wird?

    Wie kann man das noch besser gezielt danach konfigurieren dass im Falle des Verbindungsverlust wieder gemountet wird, wie läuft das ab?

  • Das Netzlaufwerk war danach immer noch erfolgreich gemountet (Netzlaufwerk ist direkt die NAS von der Fritzbox (FritzNAS))

    Der Mount ist Sache des Kernels, das heisst, Mounts sind Kernel-Objekte.... und der Kernel weiss eben nix davon, dass Du die Fritte ausgeschaltet hast. Das ist vermutlich nicht viel anders, als würdest Du kurz das Patchkabel vom NAS abziehen oder es runterfahren. Diese Kernel-Objekte überleben sogar, wenn Du das Patchkabel am PC abziehst oder schlichtweg einfach mal hart im Terminal das NIC schließt (ohne dass da jetzt noch eine Netzwerkmanagement-Sofware die Finger im Spiel hat). Der Mount als technisch-virtuelles Objekt im Kernel bleibt dabei immer bestehen.... und wenn die Verbindung wiederkommt, ist alles wieder gut. Für mich liegt der Sinn darin, dass die Mount nach unplanmäßigen Störungen von alleine wieder leben müssen, sobald die Störung behoben ist oder von alleine keine Störung mehr ist. Um die Mounts "loszuwerden", musst Du sie genau so vorsätzlich schließen, wie Du die Öffnung vorsätzlkich eingerichtet hast... oder Du bastelst Dir einen Event--Handler.... was ich aber nicht für notwendig erachte.

  • Ok vielen Dank für die Ausführung...

    da fällt mir ein, dann ists nur noch interessant was passiert, wenn keine Verbindung besteht (weil Fritzbox ausgeschaltet ist, oder kein WLAN vorhanden etc.) und der Raspberry Pi Daten auf den Mountpoint schreiben möchte, bsp. ein DD Backup mittels raspiBackup von framp oder ähnliches.

    Aber das ist wohl besser probiert als gefragt ;)

    Wobei deine Ausführungen immer sehr interessant und aufschlussreich zu lesen sind

    EDIT:

    Also mit Python läufts in eine Exception:

    Code
    connect: Das Netzwerk ist nicht erreichbar
    Traceback (most recent call last):
      File "mount_write.py", line 25, in <module>
        main()
      File "mount_write.py", line 19, in main
        with open("/media/fritz_nas/testdatei.txt", "w") as file:
    OSError: [Errno 112] Host is down: '/media/fritz_nas/testdatei.txt'

Jetzt mitmachen!

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