Mounten fstab

  • Ich bekomme es trotz Anleitungen nicht hin, meinen NAS-Server (ZyXEL NSA325;192.168.178.200) automatisch mit dem Raspberry II (Jessie 8.0)zu verbinden.

    Das manuelle mounten mit der Eingabe in der Konsole funktioniert mit : sudo mount -t cifs -o username=yyy,password=yyy-4711 //192.168.178.200/public/_ipcam /home/pi/NasShare
    und ich kann auch auf das Lauferwerk schreiben/löschen zugreifen. Somit gehe ich davon aus, dass die Laufwerkspfade und Zugriffsdaten nicht der Fehler sind.

    Wenn ich versuche jedoch eine automatische Verbindung mit Start des Raspberry umzusetzen scheidere ich. Mein Eintrag in der fstab sieht wie folgt aus:

    //192.168.178.200/public/_ipcam /home/pi/NasShare cifs username=yyy,password=yyy-4711

    oder auch

    //192.168.178.200/public/_ipcam /home/pi/NasShare cifs defaults,username=yyy,password=yyy-4711

    stellen keine Verbindung her.

    Laut Nemo bekomme ich die folgende Fehlermeldung

    Unable to mount NasShare
    mount: only root can mount //192.168.178.200/public/_ipcam on /home/pi/NasShare

    ich konnte dazu leider auch über Google keine Lösung finden und würde mich freuen wenn mir jemand behilflich wäre.

    Im Voraus, vielen Dank.

  • Ich bekomme es trotz Anleitungen nicht hin, meinen NAS-Server (ZyXEL NSA325;192.168.178.200) automatisch mit dem Raspberry II (Jessie 8.0)zu verbinden.

    So kurz Deine Angaben überflogen gehe ich davon aus, dass Du alles richtig gemacht hast. Der Grund ist vermutlich eher trivial, warum es trotzdem nicht geht. Zu dem Zeitpunkt, wenn die fstab abgearbeitet wird, ist schlicht und einfach das Netzwerk noch nicht fertig.... das heisst, die fstab failed, weil noch keine Netzwerkverbindung zum NAS besteht.

    Schau Dir diese Lösung an.... die zwei Beiträge #24 und #26 enthalten die Lösung für Dein Problem. Damit wird das mit ziemlicher Sicherheit funktionieren. Aber wie gesagt, Du brauchst beide Beiträge und Du musst unbedingt genau auf die richtige Eintragung/Übertragung Deiner Parameter achten

    milseraner
    28. November 2016 um 18:02


    HTH

    Einmal editiert, zuletzt von WinterUnit16246 (21. Dezember 2016 um 10:40)

  • Ich bleibe dabei ;)

    Ich würde dieses Mouten dem autofs-Deamon überlassen.

    https://wiki.ubuntuusers.de/Autofs/

    Auf dieser Seite wird auch etwas wichtiges, was beim PI mit Jessie immer wieder für Probleme sorgt genannt:

    Zitat


    ...
    Autofs wurde vor allem zum Einhängen von Netzwerk-Freigaben (z.B. NFS oder Samba) konzipiert. Im Vergleich zum Statischen Einbinden [6] verringert es die Belastung des Netzwerks und verbessert damit angeblich dessen Durchsatz. Weil das Einhängen zu einem späteren Zeitpunkt geschieht als die Abarbeitung von /etc/fstab, besteht keine Gefahr, dass das Netzwerk noch nicht funktioniert. Auch "Shutdown-Probleme" (z.B. beim cifs-vfs im WLAN) werden durch das automatische Aushängen vermieden.
    ...

    Böse gesagt:
    Jeder andere Vorschlag, bei einem Jessie-System Netzressourcen zu Mounten ist nur Pfusch.

    Computer ..... grrrrrr

  • Böse gesagt:Jeder andere Vorschlag, bei einem Jessie-System Netzressourcen zu Mounten ist nur Pfusch.


    Sorry, und Du nimmst mir das bitte jetzt auch nicht übel: Aber das ist totaler quatsch! Fakt ist, es wird von systemd sowieso eine Mount-Unit erzeugt, ganz egal, wie Du das NAS mountest... es wird IMMER eine mount-unit generiert. Also kann ich das auch gleich selber tun, und zwar richtig. Und selbst wenn Du es via autofs mountest, ist das Problem m.E. nicht gelöst, da autofs nichts anderes macht, als das Laufwerk erst bei Bedarf zu mounten. Im Regelfall (mit dem angemeldeten User) ist "Bedarf" so definiert, dass mit dem angemeldeten User auch das Netz verfügbar ist. Aber ab dem Moment, wo eine via systemd gestartete Unit vor der Anmeldung des Users das Laufwerk benötigt, entsteht genau das gleiche Problem... weil möglicherweise wegen fehlerhafter Einstellung der zweiten Unit zu früh "Bedarf" angemeldet wird. BTW: dein Zitat, warum autofs konzipiert wurde, bezieht sich auf die Schwächen von sysvinit.... und das auf systemd anzuwenden ist bestenfalls "unpassend". Autofs würde ich heute wirklich nur noch für Laufwerke verwenden, die ich nur seltenst verwende und die nicht immer gemountet sein sollen. Und wenn ich die Mounts von der Useranmeldung abhängig machen wollte, würde ich lieber pam-mount nutzen.

    j.m.2.c.

    Einmal editiert, zuletzt von WinterUnit16246 (21. Dezember 2016 um 11:38)

  • Zitat

    warum autofs konzipiert wurde, bezieht sich auf die Schwächen von sysvinit


    Ach deshalb hatte nie jemand mit Wheezy Probleme, wenn er eine Netzfreigabe in der FSTAB eingetragen hatte, wird hier aber immer wieder nachgefragt, warum denn bei Jessie die Netzfreigabe nicht gemountet wird.

    Eigentlich, der Idee von sysdemd zufolge, sollte die eine Unit, die die zum Mounten von Dateisystemen verwendet wird, regelmäßig selber prüfen, wenn es beim Mounten ein Problem gab oder die Unit gestört wurde, um selbständig den Fehler zu beheben.
    Also müsste, eigentlich, eine Netzfreigabe, die in der FSTAB gemountet werden soll, automatisch, ohne jede weitere Tätigkeit eines Scriptes, einer weiteren Unit, eines weiteren Programmes vom System 'nachgemoutet' werden, wenn das Netz oben ist.

    Aber das passiert nicht.

    [quote[ Autofs würde ich heute wirklich nur noch für Laufwerke verwenden, die ich nur seltenst verwende und die nicht immer gemountet sein sollen.[/quote]
    Deshalb gibt es ja auch nicht nur Konfigurationene für USB- und CD/DVD-Dateisysteme, sondern für nfs und ntfs und fat* udn CIFS/SMB.
    Weil den normale Benutzer solches ja auch als User braucht.

    Was du in dem verlinken beschrieben hast (Unit erzeugen, die den Netmount durchführt) ist eine Fehlerbehebung einer anderen Unit, die nicht wie des dem Konzept entsprechend funktioniert.
    (Ich verstärke die Hinterradbremsen meines Autos, weil die Vorderradbremsen nicht funktionieren. Ja, autofs ist etwas ähnliches, das es aber schon gibt und fehlerfrei seit langem funktioniert. Die Fehlerfreiheit deiner Lösung muss sich erst noch herausstellen)

    Übrigens, autofs hat seine Ursprünge aus dem "großen Unxi" Umfeld, dort, wo User ihr Home per NFS eingebunden bekommen, wenn sie sich anmelden.
    Wenn es dort Probleme geben sollte, dass das nicht schnell genug da wäre, hätte es schon damals mehr als Geschrei gegeben.
    Nur wenn das Netz oder der Freigabeserver weg ist, gibt es Probleme.

    Computer ..... grrrrrr


  • Ach deshalb hatte nie jemand mit Wheezy Probleme, wenn er eine Netzfreigabe in der FSTAB eingetragen hatte, wird hier aber immer wieder nachgefragt, warum denn bei Jessie die Netzfreigabe nicht gemountet wird.


    Richtig, weil systemd im Gegensatz zu sysvinit den boot nicht mehr in starrer linearer Reihenfolge abwickelt, sondern primär eben weitesgehend parallel.

    Eigentlich, der Idee von sysdemd zufolge, sollte die eine Unit, die die zum Mounten von Dateisystemen verwendet wird, regelmäßig selber prüfen, wenn es beim Mounten ein Problem gab oder die Unit gestört wurde, um selbständig den Fehler zu beheben.Also müsste, eigentlich, eine Netzfreigabe, die in der FSTAB gemountet werden soll, automatisch, ohne jede weitere Tätigkeit eines Scriptes, einer weiteren Unit, eines weiteren Programmes vom System 'nachgemoutet' werden, wenn das Netz oben ist.


    Die Idee von Systemd ist es, Prozesse zu starten, und dabei möglichst alles gleichzeitig, damit ein System gemäß Payload-Verträge bzw. vertraglich zugesicherter Systemverfügbarkeit in kürzester Zeit wieder verfügbar ist. Es ist überhaupt nicht Aufgabe eines Bootsystems darauf zu achten, ob vielleicht für irgendwelche zweit- und drittklassigen Jobs irgendwelche Abhängigkeiten erfüllt sind. Ich weiss gar nicht, wie Du auf die Idee kommst, systemd wäre dafür verantwortlich, für einen nachgeschalteten User-Mount die Netzwerkverfügbarkeit zu gewährleisten. Wie gesagt, unter Wheezy mit dem veralteten und starren sysvinit lief das alles.... träge, gemächlich eins nach dem anderen, und wenn ein Teil (vielleicht mit essentieller Aufgabe) abgekackt ist, stand vielleicht das ganze System. Ganz nebenbei bemerkt halte ich die fstab sowieso für ein überflüssiges Relikt, welches von systemd aus Gründen der Kompatibilität zur Vergangenheit noch mit geschlört wird. Notwendig ist sie jedenfalls nicht mehr.

    Es ist heute unzweifelhaft Sache des Prozesses mit seinen eigenen Problemen klarzukommen, wie z.B. dem noch unvollständigen Netzwerk, und es ist überhaupt nicht Aufgabe anderer Prozesse, ihm zuerst den Weg zu ebnen. Früher unter sysvinit mag das so gewesen sein, heute imho nicht mehr. Ich vergleiche das bildlich und i.ü.S. gerne mit dem Andrang am Eingang eines angesagten Clubs. Früher wurde ein jeder nacheinander eingelassen, in dem jedem nach Anklopfen einzeln die Tür geöffnet wurde und er dann an seinen Tisch geleitet wurde. Wenn er saß, hat sich der "Pförtner" dem nächsten Gast gewidmet. Keine Gast musste sich auf Gedränge einstellen oder ist planlos durch volle Gänge auf der Suche nach einem Tisch gestolpert. Jeder konnte sicher sein, dass alles ordentlich war, wenn er den "Laden" betreten hat, einschließlich der schon ebenso ordentlich sitzenden und wartenden Tanzpartnerinnen *lol*. Unter systemd ist das nun anders.... kein Pförtner, keine geschlossene Tür mit einzelnem Einlass, keine Begleitung bis an den Tisch, keine Ordnung in den Gängen und an den Tischen, alle kommen mehr oder weniger gleichzeitig rein und müssen selber dafür sorgen, dass sie nicht über andere stolpern und einen freien Tisch finden. Und wenn die Tanzpartnerin noch nicht am Tisch sitzt oder noch gar nicht im Club ist, so sollte er tunlichst nicht in Ohnmacht fallen, sondern einfach geduldig warten, dass seine Tanzpartnerein irgendwann selber (!) zu diesem Tisch findet. Beide sind selber für einen erfolgreichen Abend verantwortlich, und nicht der Pförtner.


    Zitat

    Was du in dem verlinken beschrieben hast (Unit erzeugen, die den Netmount durchführt) ist eine Fehlerbehebung einer anderen Unit, die nicht wie des dem Konzept entsprechend funktioniert.


    Dann hast Du das Konzept falsch verstanden. Was ich da tue, ist keine Fehlerbehandlung, sondern schlicht und einfach einen Prozess in die Lage zu versetzen, sich selber um seine Abhängigkeiten zu kümmern.... genau so, wie es sein soll.

    Zitat

    (Ich verstärke die Hinterradbremsen meines Autos, weil die Vorderradbremsen nicht funktionieren. Ja, autofs ist etwas ähnliches, das es aber schon gibt und fehlerfrei seit langem funktioniert. Die Fehlerfreiheit deiner Lösung muss sich erst noch herausstellen)


    Auch das ist eine Fehlinterpretation. Du musst bei systemd keine Bremsen verstärken, sondern einfach nur lernen, sie selber zu betätigen und was viel wichtiger ist, zu wissen, wann du sie betätigen musst, weil niemand mehr da ist, der das wie früher übernimmt. In meiner Lösung gibt es keine Fehler oder Fehlerfreiheit. Das ist nur einfachstes Customizing... mehr nicht.... einfach nur ein kleines Script, welches auf einen Server wartet, den systemd nicht kennt und an dem es richtigerweise selber gar kein Interesse hat, um dann eine nachrangige user-bezogene NAS zu mounten, was systemd an sich eigentlich völlig egal zu sein hat.

    Zitat

    Übrigens, autofs hat seine Ursprünge aus dem "großen Unxi" Umfeld, dort, wo User ihr Home per NFS eingebunden bekommen, wenn sie sich anmelden.


    Ja, richtig, hatte ich oben schon festgestellt.... wie sich "Bedarf" definiert.... früher war das so..... aber die Welt dreht sich weiter.

    Einmal editiert, zuletzt von WinterUnit16246 (21. Dezember 2016 um 15:57)

  • @TomasL
    So gut ich deine Begeisterung für systemd verstehe (ich bin derzeit "gezwungen", mich damit zu arrangieren),
    muss ich doch etwas widersprechen:

    Der Ansatz, einen Bootvorgang durch Parallelisierung zu beschleunigen, halte ich für wenig zielführend: Üblicherweise wird eine Maschine recht selten gebootet, und wenn, spielt die Zeit bis "ready for operation" nicht wirklich eine Rolle (ob der Server in 120 oder 180sec. RFO ist, ist egal: für zeitkritische "Reservesysteme" sollte man 'eh einen Server in standby haben).

    Und das OS/Bootsystem als solches sollte schon darauf achten, dass Abhängigkeiten erfüllt sind: Letztlich will ich ein in sich stabiles System und nicht erst zur Laufzeit Probleme wegen nicht erfüllter Abhängigkeiten bekommen (z.B. weil mal wieder der Zeitserver nicht (bzw. zu langsam) erreichbar ist und die Maschine über mehrere Minuten mit der falschen/unsychronisierten Zeit läuft und die Logs für einen Eventvergleich über mehrere Maschinen unbrauchbar sind) - da warte ich lieber 30sec. länger...

    Das "Problem" der erst recht spät verfügbaren Netzwerkinterface gibt es seit Jahren (auch unter SysV) und es haben sich verschiedene Lösungsmuster bewährt.
    Mir persönlich war/ist das sequentielle Starten der Dienste durch SysV lieber. Durch die Scripte in SysV konnte man ggf. auch selbst Problemlösungen einbauen (Stichwort: s99-Scripte)... wo man noch wusste, was passiert.

    Systemd nimmt dem Administrator m.M. nach zu viel aus der Hand: Man weiß nicht mehr so genau, was da wann alles hochläuft. Der Mischmasch von systemd mit dem alten SysV ist auch nicht wirklich gut (hast du ja auch schon festgestellt).

    Egal: Systemd ist im kommen und wir müssen die "saure Gurke" schlucken (ähm, ich meine, wir müssen uns damit arrangieren).

  • So gut ich deine Begeisterung für systemd verstehe (ich bin derzeit "gezwungen", mich damit zu arrangieren),


    Nun, ich kann Dir versichern, dass mich einzelne Parts eines Betriebssystems nicht wirklich begeistern *lacht* dazu bedarf es doch ein wenig mehr. Und ich bin auch kein Fanboy von systemd oder fühle mich irgendwie emotional zu systemd hingezogen... *lol*.... ganz gewiss nicht... das ist nur ein Init-System... mehr nicht. ich beurteile das ganz einfach nüchtern und sachlich und aus dem Verstehen der Unterschiede von systemd und sysvinit.


    Code
    Der Ansatz, einen Bootvorgang durch Parallelisierung zu beschleunigen, halte ich für wenig zielführend: Üblicherweise wird eine Maschine recht selten gebootet, und wenn, spielt die Zeit bis "ready for operation" nicht wirklich eine Rolle (ob der Server in 120 oder 180sec. RFO ist, ist egal: für zeitkritische "Reservesysteme" sollte man 'eh einen Server in standby haben).

    Das ist ein gerne zitierter Standpunkt, der aber einfach nix mit der Realität zu tun hat und lediglich auf einen Blick auf den eigenen Raspi basiert. Stell Dir einen Cloud-Server mit 100 oder mehr VMs vor. Da hat das Booten von Systemen dann eine völlig andere Dimension und eine lange Wartezeit bis zur vollständigen Verfügbarkeit hat sofort finanzielle Auswirkungen. Und Systemd wurde nicht für einen Bastel-Raspi entworfen, sondern eben genau für die Groß-Finanz-IT.

    Zitat

    Und das OS/Bootsystem als solches sollte schon darauf achten, dass Abhängigkeiten erfüllt sind:


    Nein, warum...?... damit hat systemd doch überhaupt nichts zu. Die Abhängigkeiten sind in den Units definiert. systemd hat lediglich die von mir definierten Abhängigkeiten einzuhalten.... ich bin verantwortlich! Natürlich gibt es auch default-Abhängigkeiten für das System an sich, aber genau die sind doch für den Faktor größtmögliche Stabilität bereits im Setup erfolgreich bedacht. Und wenn ich anfange das System mit meinen eigenen Prozessen zu verändern, dann ist es auch meine Verantwortung dafür zu sorgen, dass meine Prozesse beim Start entweder erfüllte Abhängigkeiten vorfinden, oder die Prozesse selber sind so schlau und warten auf den Zeitpunkt, wenn sie erfüllt sind. Einfach tot umzufallen tun nur die schlampig programmierten Prozesse.... oder die, die eben aus der vor-modernen Zeit stammen.

    Zitat

    Letztlich will ich ein in sich stabiles System und nicht erst zur Laufzeit Probleme wegen nicht erfüllter Abhängigkeiten bekommen


    Genau darum geht es! Aber so etwas kann niemals Aufgabe eines Init-Systems sein. Denk mal über die Bedeutung "Init-System" nach. Das soll einfach nur Prozesse starten, darüber hinaus...?... nix!

    Zitat

    Das "Problem" der erst recht spät verfügbaren Netzwerkinterface gibt es seit Jahren (auch unter SysV) und es haben sich verschiedene Lösungsmuster bewährt.
    Mir persönlich war/ist das sequentielle Starten der Dienste durch SysV lieber. Durch die Scripte in SysV konnte man ggf. auch selbst Problemlösungen einbauen (Stichwort: s99-Scripte)... wo man noch wusste, was passiert.


    Ich weiss doch unter Systemd auch, was passiert.... nur viel genauer und besser nachvollziebar. Ich halte es für völlig bekloppt, mich in eine elende lange Liste in der Startreihenfolge einzureihen, bei denen möglicherweise 95% für meinen Job irrelevant sind, bis ich dann mal dran bin. Wenn ich explizit "eine" Abhängigkeit habe, warte ich genau auf diese... fertig.... der Rest interessiert mich nicht und kann vor oder nach mir gestartet werden.

    Zitat

    Systemd nimmt dem Administrator m.M. nach zu viel aus der Hand: Man weiß nicht mehr so genau, was da wann alles hochläuft.


    Das ist hochgradig effizient und alles ist absolut nachvollziehbar. Wenn Du Dich mal intensiv damit befasst und den alten Scheiss einfach loslässt, Du wirst erstaunt sein, wie genial durchdacht das ist. Ich hatte einfach das Glück, dass relativ kurz nach nach meinem Wechsel zu Linux "Jessie" kam. Das heisst, ich hatte glücklicherweise keine lange Zeit, mich an den Mist von sysvinit zu gewöhnen. Heute, mit meinen derzeitigen Kenntnissen bereitet mir beides keine Probleme... rückwirkend erlernt... und ich bin erschrocken, wie man an sysvinit Vorteile erkennen kann.

    Zitat

    Egal: Systemd ist im kommen und wir müssen die "saure Gurke" schlucken (ähm, ich meine, wir müssen uns damit arrangieren).


    Das ist eine Einstellung, die Dir vielleicht nur Frust bescheren wird. Wenn Du systemd weiterhin mit dem Gedanken an sysvinit betreibst, kommt letzten Ende sowas raus... nix halbes und nix ganzes... und dabei hätte es ein "Hummer" sein können:
    http://bilder.t-online.de/b/41/13/97/92/…id_da/index.jpg


    j.m.2.c.

    Einmal editiert, zuletzt von WinterUnit16246 (21. Dezember 2016 um 17:42)

  • Code
    Der Ansatz, einen Bootvorgang durch Parallelisierung zu beschleunigen....

    Das ist ein gerne zitierter Standpunkt, der aber einfach nix mit der Realität zu tun hat und lediglich auf einen Blick auf den eigenen Raspi basiert. Stell Dir einen Cloud-Server mit 100 oder mehr VMs vor. Da hat das Booten von Systemen dann eine völlig andere Dimension und eine lange Wartezeit bis zur vollständigen Verfügbarkeit hat sofort finanzielle Auswirkungen. Und Systemd wurde nicht für einen Bastel-Raspi entworfen, sondern eben genau für die Groß-Finanz-IT.

    Ähm... RasPi? Interessiert mich in diesem Zusammenhang echt nicht die Bohne (auch wenn wir hier im RP-Forum sind...).
    Ich habe genau solche Server administriert (und tue es wieder, nur aktuell etwas kleiner) und:

    Der VM-Host, welcher xxx VMs hostet, sollte nicht alleine stehen, sondern zumindest eine Redundanzmaschine existieren. Der läuft normalerweise bis zum nächsten Update oder so 24/7/365 durch. Wenn das System Probleme meldet, werden die VMs auf die Redundanzmaschine geschoben, im Idealfall merkt der Anwender der VMs davon nicht mal was... (VMware will das können(!) )

    Die xxx VMs, die da laufen, werden im Normalfall ebenfalls nicht gebootet. Warum auch? Wenn die nicht gebraucht werden, hält man die an (Freeze). Die sind innerhalb weniger Sekunden wieder da... nix booten.

    Wenn eine VM neu aufgesetzt werden muss, holt man sich ein (vorbereitetes) Template oder ein komplettes, vorinstalliertes Image und fährt bootet das genau einmal (Wenn man clever ist, hat man 2-3 Reserve-VMs schon mal da (stehen im "post-boot") und lässt die im Freeze-Mode: Beim (entgültigen) Hochfahren konfigurieren die sich per cloudInit + DHCP-Server und Mamagementnode quasi selber (ok, muss natürlich alles konfiguriert werden... - die MAC ist der Key...).

    Also Boot-Orgien kann ich da jetzt nicht entdecken...


    Nein, warum...?... damit hat systemd doch überhaupt nichts zu. ....
    ...dass meine Prozesse beim Start entweder erfüllte Abhängigkeiten vorfinden, oder die Prozesse selber sind so schlau und warten auf den Zeitpunkt, wenn sie erfüllt sind. Einfach tot umzufallen tun nur die schlampig programmierten Prozesse.... oder die, die eben aus der vor-modernen Zeit stammen.

    Das eine hat mit dem anderen wenig zu tun.
    Das OS/Bootsystem hat Dienste und Resourcen bereitzustellen, ohne Wenn und Aber.
    Wenn ich Prozesse anreize, die sich auf Systemrescourcen abstützen, hab ich natürlich vorher zu prüfen, ob die Rescource a) überhaupt verfügbar (im Sinne, dass der Dienst da ist) und b) die Resource sinvoll arbeitet (im Sinne, ihren ihr zugedachten Zweck erfüllt).

    Wenn ich mounten will, muss ich zuvor prüfen, ob ein valides Netzwerk da ist und ob das Netzwerk die Resource, die ich mounten will, überhaupt bereitstellen kann (richtiges Netzwerk). Wenn das nicht der Fall ist, gibt es 2 Möglichkeiten: a) ich lass den mount-prozess warten, bis das Netzwerk da ist oder b) "late mount" im s99-Script: Dort wird geprüft, ob alle mounts da sind und wenn nicht, wird der Mount retriggert (+ timeout usw...)


    Genau darum geht es! Aber so etwas kann niemals Aufgabe eines Init-Systems sein. Denk mal über die Bedeutung "Init-System" nach. Das soll einfach nur Prozesse starten, darüber hinaus...?... nix!

    Darüber lässt sich endlos streiten:
    Für mich (und Kollegen) dient das "init" System die Initialisierung der Maschine bis zum Status RFO. Der gesamte Init-Prozess ist unterteilt in viele SubSteps und Etappen... welche letztlich alle von den Startscripten des SysV oder systemd angereizt werden.
    Ist das letzte Script durchgelaufen ist der Init-Prozess beendet und die Maschine könnte ihre ihr zugedachte Aufgabe beginnen.
    Und zu diesem Zeitpunkt gibt es einen oder mehrere Werte (keys) die _alle_ auf "ok" zu zeigen haben ("alles ordnungsgemäß initialisiert").
    Erst dann werden die Worker-Prozesse gestartet.


    Ich halte es für völlig bekloppt, mich in eine elende lange Liste in der Startreihenfolge einzureihen, bei denen möglicherweise 95% für meinen Job irrelevant sind, bis ich dann mal dran bin. Wenn ich explizit "eine" Abhängigkeit habe, warte ich genau auf diese... fertig.... der Rest interessiert mich nicht und kann vor oder nach mir gestartet werden.


    Dieser Meinung kannst du sein, aber letztlich ist das wie bei der Armee oder im Orchestergraben:
    Der Einzelne hat sich dem Ganzen unterzuordnen und genau seine Aufgabe zum richtigen Zeitpunkt zu tun. Unterstützt wird er von seinem Anführer durch entsprechende Hinweise/Kommandos.

    Ob ihm das jetzt passt oder nicht ("ich will aber JETZT trommeln") spielt keine Rolle und gefährdet in Fall der Nichteinhaltung den Gesamterfolg.



    Das ist hochgradig effizient und alles ist absolut nachvollziehbar. Wenn Du Dich mal intensiv damit befasst und den alten Scheiss einfach loslässt, Du wirst erstaunt sein, wie genial durchdacht das ist. Ich hatte einfach das Glück, dass relativ kurz nach nach meinem Wechsel zu Linux "Jessie" kam. Das heisst, ich hatte glücklicherweise keine lange Zeit, mich an den Mist von sysvinit zu gewöhnen. Heute, mit meinen derzeitigen Kenntnissen bereitet mir beides keine Probleme... rückwirkend erlernt... und ich bin erschrocken, wie man an sysvinit Vorteile erkennen kann.

    Diese Sätze hast du auch in anderen Threads schon mehrfach wiederholt und sysV-Anhänger damit versucht abzubürsten (Deine Wortwahl halte ich mindestens für "misslungen" ... die Leute, die sich das ausgedacht haben, waren keine I d i o t e n !)

    Ich habe mich da bisher weitestgehend zurück gehalten, aber ich kann dir sagen, dass ich mit der IT begonnen habe, als eine PDP11 was "ganz Tolles" war und ich seit ca. 20 Jahren mit HPUX, SunOS und RedHat/Centos zu tun habe und wir mit SysV bisher sehr gut gefahren sind...


    Das ist eine Einstellung, die Dir vielleicht nur Frust bescheren wird. Wenn Du systemd weiterhin mit dem Gedanken an sysvinit betreibst, kommt letzten Ende sowas raus... nix halbes und nix ganzes... und dabei hätte es ein "Hummer" sein können:

    Mach dir mal keine Sorgen um meine Einstellung :lol:
    bis jetzt treten Problem, die ich habe, nur in Zusammenhang mit Produkten junger/frischer/engagierter SW-Entwickler der Open-Source-Scene auf, die mit Hyper-Tuper-Klick-und-wech Code um sich werfen ("Testen? - ähm, keine Zeit", "Abwärtskompatibilität? - ähm warum?", "Dokumentation? - ähm, steht im Code..." usw....)

    In diesem Sinne... bin erstmal raus - muss mich jetzt noch mit InfluxDB beschäftigen - auch wieder so eine SW, wo die Doku eher mäßig ist (aber der Web-Auftritt sieht zumindest gut aus... :denker: )

  • Das witzige ist doch, dass bei meinem Wheezy mit InitV der NFS-Prozess, wenn er starten will, meldet, dass das Netzinterface noch nicht fertig ist, und immer wieder versucht, gestartet zu werden, bis das Netz oben ist.
    (Standard Init-Verlinkung vom Debian)

    Es geht also beim 'alten' Init.

    Und wenn systemd einen parallelen Start möglichst vieler Prozesse ermöglichen soll, und auch selber testen soll, ob alles sauber läuft, dann soll es gefälligst das auch beim Mounten der in der FSTAB stehenden Mounts machen.
    DAS IST SEINE VERDAMMTE PFLICHT VOM SYSTEMD.
    Dafür wurde es (auch) entwickelt.

    Wenn es nun eben nicht schafft, das Mounten sauber abzuhandeln (weil das Netz noch nicht da ist), und diese Unit es nicht auf die Reihe bekommt, die Netzmounts 'nachzumounten', dann ist das ein Fehler dieser Unit.

    Aus, ende.

    Und wenn du eine Unit schreibst, die den Fehler der UNit ausbügelt, die mounten soll, ist das eben eine Fehlerbehebung.
    Nichts anderes.

    Und, lieber ThomasL, du versucht diesen Fehler abzustreiten.

    Zitat

    Ja, richtig, hatte ich oben schon festgestellt.... wie sich "Bedarf" definiert.... früher war das so..... aber die Welt dreht sich weiter.


    Ach, deshalb gibt es auch keine unaussprechlichen Befehle mit noch schlimmeren Kommandozeilenparametern mehr.
    Denn in den letzten 30 Jahren hat sich ja herausgestellt, dass man die alle nicht wirklich braucht.
    So wie man die Kommandozeile nicht mehr braucht.
    (Siehe Windows, MacOS, Ubuntu)


    Übrigens, der Befehl "which" hat einen vollkommen falschen Namen. Denn er soll ja den Pfad zu einem Programm anzeigen, das im Pfad liegt. (Wo liegt dieses dämliche Programm nur?)
    Da wäre "where" sehr viel sinnvoller.
    (Das es bei Windows mit genau diesem Namen gibt ;-))

    Computer ..... grrrrrr

  • Diese Sätze hast du auch in anderen Threads schon mehrfach wiederholt und sysV-Anhänger damit versucht abzubürsten (Deine Wortwahl halte ich mindestens für "misslungen" ... die Leute, die sich das ausgedacht haben, waren keine I d i o t e n !)


    Zu keiner Zeit würde ich behaupten, dass 1992 die Entwickler von SystemV Idio ten waren. Ebensowenig würde ich jemals behaupten, dass vor 25 Jahren die Entwickler von "sudo" Idio ten waren. Wir stehen heute aber vor dem Jahreswechsel nach 2017. Beides ist damals zu einer Zeit entstanden, als nichts von dem, was heute üblich ist, vorstellbar oder in dieser Ausprägung vorhersehbar war. Es gab auch mal eine Zeit, in der eisenbeschlagene Holzräder den Stand der Entwicklung markiert haben. Auch die, die diese Räder erfunden haben, waren zu der Zeit keine Idio ten. Aber allen Dreien ist gemeinsam, dass sie aus heutiger Sicht den gleichen Stellenwert haben, wie ein C64 oder ein Apple 2c: Es ist für moderne Aufgaben alter und untauglicher Schrott. Du hast Recht, meine Meinung ist bedeutungslos und keinesfalls für igendwas maßgeblich. Aber Du täuscht Dich, wenn Du mir das Interesse unterstellst, ich wolle jemand abbürsten.... ich versuche nur deutlichzu machen, dass man ein eisenbeschlagenes Holzrad nicht mit einem Luftreifen gleichsetzen kann. Fakt ist, die sysvinit-Lösungen funktionieren zum Teil nicht mehr.... daran ist nicht zu rütteln.... ebensowenig wie das Pferdefuhrwerk auf der Autobahn funktioniert. Ich werde aber nun trotzdem dankbar Deinen Rat annehmen und künftig meine misslungene Wortwahl zügeln und stattdessen die alten Lösungsansätze mit Interesse verfolgen ... und mich ggf. darüber freuen, wenn sie noch mal erfolgreich sein dürfen.

    Einmal editiert, zuletzt von WinterUnit16246 (21. Dezember 2016 um 22:16)

  • Zurück zum Thema. Ich hab mein NSA 325 so in der fstab eingebunden:

    Code
    //NAS_IP/Pfad/rpi_backup /media/nas_share cifs username=NAS_USER,password=NAS_PASSWORT,uid=PI_USER,gid=PI_GROUP 0 0

    //NAS_IP/Pfad/rpi_backup ... Freigabe auf dem NAS


    /media/nas ... Ordner auf dem PI, wo die NAS-Freigabe eingebunden werden soll

    uid=PI_USER,gid=PI_GROUP ... User-ID und Gruppen-ID des Users auf dem PI, auf dem das NAS eingebunden werden soll.

    Willst du einen Tag lang glücklich sein, dann saufe.

    Willst du ein Jahr lang glücklich sein, dann heirate.

    Willst du ein Leben lang glücklich sein, dann fahr Yamaha.

Jetzt mitmachen!

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