Login
Newsletter
Werbung

Thema: Systemd startet bei Fehler vorhergehende Kernel-Version

75 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
3
Von Anonymous am Do, 25. Oktober 2018 um 10:07 #

Jetzt fehlt noch eine Automatik, die bei systemd-Problemen dir frühere systemd-Version herstellt.

Boah, ich hasse den Scheiss mit seinen ünübersichtlichen 250 Units. Auf Servern mag das ja sinnvoll sein, auf einem Desktop-System ist das totaler, durch normale Anwender unwartbarer Overkill.

  • 4
    Von Mandri am Do, 25. Oktober 2018 um 10:55 #

    Wie kommst du darauf, dass der "normale Anwender" da etwas warten müsste?
    Der kommt mit den "unübersichtlichen 250 Units" doch nicht in Berührung.

    • 2
      Von Anonymous am Do, 25. Oktober 2018 um 21:28 #

      Ein- oder zweimal im Jahr kommt man damit in Berührung, aber zu selten, dass es sich lohnt das zu lernen (um es wegen der seltenen Anwendung bis zum nächsten Mal wieder zu vergessen).

      Z.B., um auf seinem RasPi-Webradio einen automatischen Login (auf der Kommandozeile) einzurichten.

      Das ist noch halbwegs übersichtlich, weil man ein zusätzliches Feature einrichtet. Schwierig wird es, wenn man alles deaktivieren möchte, was man nicht braucht.

      Das ist dann ähnlich wie bei Windows7 mit seinen 80 Systemdiensten, die alle scheinbar hierarchiefrei in der Systemdienste-Rumpelkammer rumliegen. Aber: "Wenn sie diesen Dienst deaktivieren, werden alle von diesem Dienst abhängigen Dienste nicht mehr funktionieren". Nur welche das sind, erkannte man da nicht, sondern merkte erst nach einiger Zeit, dass der abgeschaltete Mist wohl doch wichtig war.

      Dank systemd habe ich jetzt Windows7-"Komfort" auf 95% der Distributionen.

      • 2
        Von Mandri am Do, 25. Oktober 2018 um 22:03 #

        "Z.B., um auf seinem RasPi-Webradio einen automatischen Login (auf der Kommandozeile) einzurichten.

        Das ist noch halbwegs übersichtlich, weil man ein zusätzliches Feature einrichtet. Schwierig wird es, wenn man alles deaktivieren möchte, was man nicht braucht."

        Du meinst, wenn du den Admin spielst?
        Ja, dann solltest du schon ein Bisschen Ahnung haben.

        Und jetzt mal im Ernst, was ist denn die Alternative? In Config-Dateien rumfingern?

        Man muss ja systemd nicht mögen, aber die Kritik sollte wenigstens ehrlich sein.

    4
    Von Trollfänger am Do, 25. Oktober 2018 um 10:56 #

    Jetzt fehlt noch eine Automatik, die bei systemd-Problemen dir frühere systemd-Version herstellt.

    Merkst du eigentlich, dass deine Forderung dem widerspricht, was du im nächsten Absatz ankreidest?
    Und nein, dein Beitrag enthält keine "Ironie"!

    Boah, ich hasse den Scheiss mit seinen ünübersichtlichen 250 Units. Auf Servern mag das ja sinnvoll sein, auf einem Desktop-System ist das totaler, durch normale Anwender unwartbarer Overkill.

    Bei solchen unüberlegten Kommentaren bin ich froh, dass die Ausrichtung von Linux nicht von Desktopklickern bestimmt wird.

    Dann wollen wir doch einmal konkruktiv an diesen »Kommentar« herangehen.

    Welche Alternativen siehst du?
    Entfernen wir mal von deinem Einzelplatzsetup, und bewegen uns in den professionellen Bereich die bekanntlich nicht mehr jedes System einzeln administrieren und warten, sondern eine Systemmanagement Toolkit zum Einsatz bringen.

    Und die meisten dieser Systemmanagement Toolkits setzen eben systemd voraus.

    Einmal ganz davon abgesehen, du solltest aufhören hier herumzuheulen, und die Möglichkeiten der Technologie nutzen (lernen).
    Du wirst die Entwicklung weder stoppen, noch zurückdrehen, selbst mit einem Meer aus Tränen _nicht_!

    Aber es steht dir natürlich frei, eine Distribution zu finden, die kein systemd für das Initialisieren und das Systemmanagement verwendet.
    Oder du schaust dich nach einem anderen OS um, welches nicht dieses pöse systemd einsetzt.

    Win-Win für beide Seiten, du musst dich nicht, mit dieser "fürchterlich komplizierten" Technologie beschäftigen und wir müssen uns keine Heulorgien mehr antun.

    Und nun noch einen schönen, erkenntnisreichen Tag!

    • 3
      Von Jan2 am Do, 25. Oktober 2018 um 11:04 #

      Das ist gut gemeint von Dir, bringt aber überhaupt nichts.

      Die Leute die sich gegen systemd aussprechen haben sich nicht ernsthaft damit beschäftigt.
      Im Heise-Forum ist der gleiche Unsinn los.

      systemd ist sinnvoll, mir wären die Logs allerdings in plaintext lieber.
      Und es ist in Anlehnung vom Systemstart von Solaris und MacOS entworfen worden.

      tschüß, Jan

      • 5
        Von Trollfänger am Do, 25. Oktober 2018 um 11:23 #

        mir wären die Logs allerdings in plaintext lieber.

        Kannst du haben, installier auf deinem System(en) einen Log Daemon (z.B. rsyslogd) und journald reicht seine "Logs" plaintext an diesen weiter.
        Mir ist klar, dass du diese Funktion gern in systemd selber sehen würdest, aber dieser Workaround funktioniert ganz gut.
        Gegebenenfalls müssen noch einige Konfigurationen bei deiner Distribution vorgenommen werden?
        Meines Wissens nach gibt es bereits ein Ticket zum journald plaintext, dieses hat aber eine niedrige Priorität, weil erst einmal alle Features in systemd integriert werden sollen.

      2
      Von Anonymous am Do, 25. Oktober 2018 um 12:31 #

      Entfernen wir mal von deinem Einzelplatzsetup,

      Also von dem Thema, von dem ich ausdrücklich rede.

      Aber es steht dir natürlich frei, eine Distribution zu finden, die kein systemd für das Initialisieren und das Systemmanagement verwendet.

      Die habe ich schon.

      • 2
        Von Trollfänger am Do, 25. Oktober 2018 um 12:42 #

        Also von dem Thema, von dem ich ausdrücklich rede.

        Die frage ist doch, wenn interessiert dein Einzelschicksal?

        Die habe ich schon.

        Und warum heulst du dann immer noch?
        Bekommst du etwa zu wenig Aufmerksamkeit?
        Oder ist es dir einfach nicht gegeben, auch einmal zu schweigen, wenn es angebracht wäre?

        3
        Von ano am Do, 25. Oktober 2018 um 14:27 #

        Welche Distribution verwendest du?

        Ich habe auf meinem Hauptsystem Devuan installiert und bin damit sehr zufrieden.


        ano

        • 3
          Von Anonymous am Do, 25. Oktober 2018 um 15:16 #

          Slackware. Und als Alternativ-Distro ebenfalls Devuan.

          • 2
            Von Trollfänger am Do, 25. Oktober 2018 um 16:15 #

            Slackware. Und als Alternativ-Distro ebenfalls Devuan.

            Die Frage ist immer noch unbeantwortet, warum heulst du, wenn du kein systemd verwendest? Was genau ist denn dann dein Problem?

            • 3
              Von Anonymous am Do, 25. Oktober 2018 um 16:34 #

              Weil sie cher Scheiss wir ein Ballmersces krebsgeschwür in zahlreiche Distributionen reingefressen hat. Und weil mein Raspbian mit dem für mich unwartbaren Scheiss "gesegnet" ist

              2
              Von ano am Do, 25. Oktober 2018 um 20:39 #

              Benutz doch einfach systemd, wenn du damit zufrieden bist. Ich verwende es halt nicht.

              Es ist mir eigentlich auch egal, warum du es verwendest. Genauso wenig interessiert mich dein Lieblingsdesktop, Lieblingstexteditor oder Lieblingsbrowser. Und (völlig überraschend): ich möchte dich auch gar nicht von meinem Lieblingsdesktop, Lieblingstexteditor oder Lieblingsbrowser überzeugen!

              Es ist doch einfach toll, dass wir so viel Auswahl haben!!


              ano

              PS: Ich bin nicht der Anonymous von oben; mich interessierte nur seine Distribution, da es nicht so viele Distributionen gibt, die nicht auf systemd setzen und wir bzgl. des Init-Systems offensichtlich ähnliche Vorlieben haben.

          2
          Von Anonymous am Do, 25. Oktober 2018 um 15:20 #

          Ergänzung: Auf dem RasPi bin ich noch mit systemd konfrontiert (Raspbian).

          • 2
            Von ano am Do, 25. Oktober 2018 um 20:29 #

            Geht mir genauso... ;-)
            Auf dem raspberry komme ich momentan nicht an systemd vorbei - raspbian ist einfach zu gut angepasst, als das ich es ersetzen möchte.

            Slackware wäre meine Ausweichoption - hatte ich ganz früher mal auf dem Rechner.

            Devuan läuft richtig gut, geradezu langweilig gut.

            ano

    3
    Von AnotherAnonymous am Do, 25. Oktober 2018 um 20:56 #

    > Jetzt fehlt noch eine Automatik, die bei systemd-Problemen dir frühere systemd-Version herstellt.

    Oder sich selbst deinstalliert und ein anders Init installiert... :angel:

    1
    Von DieGesellschaftDerArkanoiden am Fr, 26. Oktober 2018 um 23:30 #

    Auf Servern mag das ja sinnvoll sein, auf einem Desktop-System ist das totaler, durch normale Anwender unwartbarer Overkill.

    Nich' doch. Allenfalls anders herum wird ein Schuh draus.

    • 2
      Von Verfluchtnochmal-05995bd7b am Sa, 27. Oktober 2018 um 12:02 #

      Nein

      90% der systemd Features sind auf Servern wesenlich spannender, aber dazu müsste man sich mal damit auseinander gesezt haben und dann könnte man nicht trollen


      Jetzt gehts du mal die einzelnen Optionen googeln und bevor nicth verstanden hast wovon du sprichst kommst du nicht zurück

      CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID
      MemoryDenyWriteExecute=yes
      NoNewPrivileges=yes
      PrivateDevices=yes
      PrivateTmp=yes
      ProtectControlGroups=yes
      ProtectHome=yes
      ProtectKernelModules=yes
      ProtectKernelTunables=yes
      ProtectSystem=strict
      RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX
      RestrictRealtime=yes
      SystemCallArchitectures=x86-64
      SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap
      ReadWritePaths=/var/lib

      • 1
        Von DieGesellschaftDerArkanoiden am So, 28. Oktober 2018 um 02:38 #

        Du hast die Unix-Philosophie ja durchdringend verstanden. Viel hilft viel, ist kein sinnvolles Konzept für Betriebssystemkonponenten.

        Und sowas kommt dann aktuell dabei raus (wahlfrei aus dem Pool der Bloatware gegriffen):

        While the check at (A) tries to ensure that the buffer has enough space left to store the IA option, it does not take the additional 4 bytes from the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow in (D) giving an attacker a very powerful and largely controlled OOB heap write starting at (E).

        Geh' doch mal in die Natur. Das entspannt ungemein. Verprochen! Viel Freude dabei :-)

        • 0
          Von Verfluchtnochmal-05995bd7b am Mo, 29. Oktober 2018 um 10:35 #

          Was kann ich dafür dass du von systemd so wenig AHnung hast um dich in die "folgt nicht der Unix-Philosophie" Kasper einzureihen, schau mal wieviele einzelne Binariues das sind die nur zufällig im selben Source-Trre mainatined werden statt dutzender kleiner Projekte wo man dann immer auch ganz genau schon muss ob ja alle minor versionen passen um keine unliebsamen Überraschungen zu erleben

2
Von Peekaboo am Do, 25. Oktober 2018 um 10:40 #
4
Von Jürgen Sauer am Do, 25. Oktober 2018 um 11:48 #

Die Akzeptanz wird immer wieder von neuem beschädigt.

Das Problem ist:

Gut gemeint,
fehlerhaft gemacht,
neue Features werden überstürzt eingeführt,
bevor man essentielle Bugs zuvor gefixt hat,
"der Fehler liegt immer bei den Anwendern Haltung" (arrogante Entwickler), die die Alltagsproblematik nicht einsehen wollen.

Siehe auch hierzu:
https://github.com/systemd/systemd/issues

Man mache sich einfach selber ein Bild.

Leider ist man bei allen wesentlichen Distributionen im Alltagsbetrieb dem Treiben von systemd hilflos ausgeliefert.

Da muss man zähneknirschend durch. :cry:

  • 2
    Von thematsche am Do, 25. Oktober 2018 um 12:44 #

    Ja, genau so isses!

    4
    Von mw am Do, 25. Oktober 2018 um 12:47 #

    Das ist nicht nur einProblem von systemd. Auch andere SW-Systeme haben die gleichen Probleme.

    Ich möchte hier gar nicht öffentlich über Ursachen diskutieren. Eine Distro mit systemd ist in meinem Umfeld einfach nicht denkbar. Die schiere Kompliziertheit und bei der mangelhaften Reife kommen dann noch jede menge Überraschungen dazu, verbietet einfach einen Einsatz in Systemen, die a) hochverfügbar sein müssen und b) eine Lebensdauer von 25 Jahren haben. Und komme mir keiner mit Updates, meine Kunden können es sich nicht leisten, durch einen Update Produktionsausfälle zu erleiden, nur weil das unausgegoren und nur teilweise getestet war.

    Die Komplexität des GNU/Linux Ecosystems muß dringend reduziert statt laufend gesteigert werden.

    Da ist systemd halt ein Paradebeispiel, wie es nicht laufen soll. Von charakterlichen Defiziten seiner Protagonisten mal abgesehen. Noch was: one size fits all, funktioniert nicht nur bei Unterhosen nicht, sondern auch nicht bei GNU/Linux und systemd.

    • 4
      Von Verfluchtnochmal-05995bd7b am Do, 25. Oktober 2018 um 13:14 #

      Aha und der Wahnsinn von Shellsripts war einfacher und robuster als INI-Style Configs mit drop-ins und ganz klaren Hirarchien was und wo du so overriden kannst dass es ganz sicher bei Updates nicht angefasst wird?

      Sorry, komplette Infrastruktur seit 2008 auf Fedora und seit 2011 damit auf systemd - Wenn du durch Updates Produktionsausfälle erleidest bist du einfach nur unfähig und solltest dir überlegen wie es andere schaffen Systeme zu klonen und Updates so lange durchzuspielen bis selbst ein Dist-Upgrade in unter 2 Minuten und mit einem Reboot wie bei jedem anderern Kernel-Update auch erledigt ist

      Schon mal was von Virtualisierung gehört?

      • 1
        Von McSpinsay am Do, 25. Oktober 2018 um 13:44 #

        Genau. Vortualisierung drumherum und ab in die Blockchain und alle deine Probleme sind gelöst!

        • 4
          Von Verfluchtnochmal-05995bd7b am Do, 25. Oktober 2018 um 14:06 #

          Nein es sind nicht alle Probleme gelöst aber wer heute noch mit phyischen Rechner in Produtivumgebungen rumspielt muss halt alle Setup-Typen doppelt vorhalten zwecks Tests wenn er es nicht gebacken bekommt eine moderne Infrastruktur aufzusetzen

          Aber Geheule von wegen Produktionsausfällen durch Updates zeigt nur die absolute Inkompetenz des Verfassers und wenn es an Zeit/Budegt/Qualifikation mangelt Tests zu implementieren kann man sich das zwar schön reden und systemd die Schuld geben, es ändert aber nichts am eigenen Totalversagen

          • 3
            Von mw am Do, 25. Oktober 2018 um 15:18 #

            Totalversagen ist dein Beitrag. Und von Automatisierung hast Du asolut überhaupt keine Ahnung. Aber was solls, das hier ist für IT Frickler, nicht für Ingenieure. Sorry muss, aber mal gesagt werden.

            Immer schön den anderen unfähig nennen, anstatt die Probleme anzupacken. Typisch IT.

            • 4
              Von Verfluchtnochmal-05995bd7b am Do, 25. Oktober 2018 um 15:55 #

              Na offenbar schon weil ich seit mehr als 10 Jahren automatisierte Tests schaffe mit und ohne systemd und mit Major-Upgrades 2 mal pro Jahr ohne Produktionsausfälle

              Ihr offenbar nicht, stattdessen sucht ihr die Schuld bei systemd statt bei der eigenen Unfähigkeit

      1
      Von ano am Fr, 26. Oktober 2018 um 08:54 #

      Ich kann deine Argumentation im Prinzip nachvollziehen, aber welches System bietest du dann deinen Kunden an? Wie bereits schon geschrieben wurde, setzen alle großen Distributionen mittlerweile auf systemd: Debian, Red Hat, Suse, Ubuntu, ...
      Selbst Arch, das ja den eigentlich den Fokus auf "Keep it simple" legt, verwendet systemd.

      Das soll kein Argument für oder gegen systemd sein.

      ano

      • 3
        Von tomkater68 am Fr, 26. Oktober 2018 um 09:26 #

        Selbst Arch, das ja den eigentlich den Fokus auf "Keep it simple" legt, verwendet systemd.

        Systemd widerspricht dem 'Keep it simple' in keinster Weise, denn Arch Linux definiert Einfachheit wie folgt:

        Arch Linux defines simplicity as without unnecessary additions or modifications. It ships software as released by the original developers (upstream) with minimal distribution-specific (downstream) changes: patches not accepted by upstream are avoided, and Arch's downstream patches consist almost entirely of backported bug fixes that are obsoleted by the project's next release.
        ( siehe https://wiki.archlinux.org/index.php/Arch_Linux#Principles )

        Einfach im Sinne von Arch ist also die unveränderte Übernahme der Software vom Upstream. Wesentlich für die Einfachheit im Sinne von Arch ist, dass die Konfiguration von Software so erfolgt, wie es von den Entwicklern vorgesehen ist und von Seiten der Distribution keine zusätzlichen (GUI) Tools zur Konfiguration hinzugefügt werden. Wer Einfachheit als 'leichtgewichtig' oder 'einfach zu bedienen' interpretiert, der wird sich bei Archlinux ein blaues Auge holen.

        • 2
          Von Jürgen Sauer am Fr, 26. Oktober 2018 um 20:26 #

          Auch wir verwenden hier Arch, wegen der "Ursprünglichkeit".

          Was wir aber hassen, ist die Arroganz der Systemd Protagonisten, erstmal alle Fehler beim Anwender/Admin zu suchen.

          Was uns hier am meisten geärgert hat:
          - defekte mount einbindung aus der fstab
          -- /home ist via NFS gemounted,
          -- /home/$user/[.local|.cache] sind btrfs subvols um dein DDOS gegen den NFS Server zu vermeiden, sonst liegt bei Arbeitsbegin, wenn die User hochfahren und einloggen der NFS server in der Ecke ...

          Hier zeigen sich fatale Fehler:
          1. /home mounted nicht, weil netwok.target falsch "online" meldet
          2. obwohl /home nicht gemountet ist, werden fröhlich die /home/$user/.local mount eingehängt ...

          - systemd-networkd-wait-online ist schlicht defekt:
          -- unzuverlässige Netzwerk Aktivierung beim Booten
          -- False Positive "Network up/Online" detection
          -- defekte Link Detection spziell wenn Bridged/Bonded devices im Spiel sind

          Von network.target, systemd-networkd und systemd-networkd-wait-online abhängige units knallen dann total.

          Bug gemeldet, und von Poettering ignoriert ... seit 2! Jahren offen
          :evil:

          • 2
            Von Verfluchtnochmal-05995bd7b am Fr, 26. Oktober 2018 um 23:50 #

            > /home mounted nicht, weil netwok.target falsch "online" meldet

            Vielleicht mal versuchen den Unterschied zwischen "network-online.target" und "netwok.target" verstehen dann wird es einfacher!

            Mein "network-wan.service" der für eine DHCP-Adresse und Bridges sorgt hat "WantedBy=network.target", ist also Teil des "network.target" und wenn das und alles andere in "network.target" fertig ist kommt "network-online.target" zum Tragen

            Und ja das macht Sinn und Nein mit sysvinitscripts war das nicht besser sondern nur scheisse langsam und im worst case ist der komplette Bootvorgang hängen geblieben

            2
            Von Verfluchtnochmal-05995bd7b am Sa, 27. Oktober 2018 um 15:33 #

            Und zu

            > obwohl /home nicht gemountet ist, werden fröhlich die /home/$user/.local mount eingehängt

            Einfach mal die Dokus lesen, Condition* funktiniert fehlerfrei, seit Jahren, wenn es komplexer wird ist /etc/fstab schlichtweg das falsche Tool, dafür gibt es mount-units in denen du DInge ausdrücken kannst die die fstab im Traum nicht hergibt

            Euer Hauptproblem scheint zu sein dass ihr euch eben nicht wirklich eingearbeitet habt und gerne alles wie früher hättet, wenn man mal wirklich die Konzepte hinter systemd verstanden hat ist das wesentlich einfacher zu handhaben als das Geschiss von Shellscripts die alle ihre eigene Semantik haben und voller Workarounds sind die sich auch noch zwicshen Distributionen unterscheiden

            ConditionArchitecture=, ConditionVirtualization=, ConditionHost=, ConditionKernelCommandLine=, ConditionKernelVersion=, ConditionSecurity=, ConditionCapability=, ConditionACPower=, ConditionNeedsUpdate=, ConditionFirstBoot=, ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable=, ConditionUser=, ConditionGroup=, ConditionControlGroupController=

            1
            Von schmidicom am Sa, 27. Oktober 2018 um 15:55 #

            Na dann Link mal diesen Bugreport...

            EDIT:
            Hab den Bugreport selbst gefunden und wie vermutet sind nahezu alle von dir gemeldeten Probleme auf zwei Ursachen zurück zu führen. Erstens werden Abhängigkeiten unzureichend oder sogar falsch definiert was bei einem parallelen boot wie systemd ihn verwendet nicht funktionieren kann. Und zum zweiten ist deine mount-Konfiguration so komplex das die fstab bei einem parallelen boot schlicht der falsche Platz ist um so etwas zu konfigurieren.

            EDIT2:
            Das erste was du in den Griff bekommen müsstest wäre das was du in network.target und network-online.target "installiert" hast. Bei meinen Client-Rechnern ist es (in beiden Traget's) der NetworkManager und bei den Servern systemd-networkd. Und eigentlich funktionieren beide einwandfrei so lange ihnen kein anderes Tool (wie zum Beispiel eben libvirt) dazwischen funkt. Es gibt im Internet etliche Anleitungen darüber wie man systemd-networkd und libvirt fehlerfrei kombiniert und es wäre wohl nicht verkehrt sich die mal anzusehen.

            Das zweite sind die etlichen in einander verschachtelten Einträge aus deiner fstab. Abgesehen von root, boot und swap müsste jeder Eintrag daraus in ein von dir erstelltes mount-Unit mit sauber definierten Abhängigkeiten (also mit korrekten "Requires" und "After" Optionen in der Unit-Sektion) umziehen. Der Generator den systemd für die Einträge aus der fstab-Datei anbietet ist nicht für ein so komplexes Gebilde wie das deine programmiert worden und sollte es auch nicht.

            Bug gemeldet, und von Poettering ignoriert ... seit 2! Jahren offen
            Ich kann ja deine Frustration zwar verstehen aber "ignoriert" hat dich niemand. So wie ich das sehe hat man trotz der Ausgangslage versucht dir zu helfen...

            Dieser Beitrag wurde 6 mal editiert. Zuletzt am 29. Okt 2018 um 12:30.
            2
            Von Verfluchtnochmal-05995bd7b am Sa, 27. Oktober 2018 um 19:10 #

            Und nur damit du es verstehst:

            After=network-online.target
            Requires=network-online.target

            Das sind die beiden Zeilen die deinem Service sagen "Du startest wenn das Netzwerk wirklich da ist", "Von network.target, systemd-networkd und systemd-networkd-wait-online abhängige units knallen dann total" ist damit reiner Bullshit weil du nicht von einzelnen Diensten abhängig bist sondern von Targets und da solltest du halt auch die richtigen benutzen

            /usr/lib/systemd/system/systemd-networkd-wait-online.service:
            [Install]
            WantedBy=network-online.target

            Und da sind wir wieder am Beginn: Basics verstehen dann klappt das auch weil "systemd-networkd-wait-online.service" ist ein SUBSET von "network-online.target"

            1
            Von Warum plötzlich so leise? am Di, 30. Oktober 2018 um 00:03 #

            Erst ganz gross behaupten irgendwas wurde ignoriert weilalle böse sind und wenn deine Unfähigkeit mehrfach bewiesne wurde kein Wort mehr? Sagt auch einiges aus.... Aber das hast du mit so ziemlich allen die über systemd schimpfen gemeinsam: Viel Meinung für bei wenig Ahnung

1
Von schmidicom am Do, 25. Oktober 2018 um 13:52 #

Jedem Programmierer wird eingetrichtert keine potenziellen Endlosschleifen zu fabrizieren und deshalb immer so etwas wie einen Schleifenzähler zu verwenden. Aber kaum macht systemd im Bezug auf den Boot-Vorgang etwas ähnliches ist schon wieder der Teufel los...

Ich finde das Feature jedenfalls gar nicht so verkehrt und innerhalb von systemd auch alles andere als fehl am Platz.

0
Von Einer, der es satt hat am Di, 30. Oktober 2018 um 16:55 #

... kloppen sich die Glaubenskrieger.

Hinweis: ich lese eure Kommentare nicht. Es ist mir egal, welcher Templer die ultimative Wahrheit gepachtet hat. Tschüss ...

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung