Systemd Vor- und Nachteile

  • Systemd: "find' ich super!" oder "*würg*, weg damit"? 14

    1. super! (11) 79%
    2. *würg* (3) 21%

    Hier gibt es ja ab und zu geteilte Meinungen zu systemd. Manch User empfiehlt immer: "Das würde ich mit einer Systemd-Service-Unit machen!", andere verfluchen es und schwelgen in Erinnerungen an die guten alten Zeiten, als SysVinit der absolute Hit war. Es gibt sogar Seiten von Radikalen (ohne eine Idee von Webdesign): https://without-systemd.org.


    Was sind, aus eurer Sicht die genialen Vor- oder grausamen Nachteile von Systemd? Was verwendet ihr auf euren Raspis, Servern und Desktop-Rechnern?


    Edit: Sehr amüsant -> https://www.google.de/search?q=systemd+meme&tbm=isch <-

  • Ich finde es mittlerweile genial, obwohl systemd mir bei der Einführung in Raspbian absolut auf den Keks gegangen ist.

    Ich finde es sehr flexibel und ich kann z.B. services definieren, die bei Absturz (der ja nicht vorkommen sollte) automatisch neu gestartet werden.

    Damit entfällt ein evtl. sonst notwendiger, anwendungsspezifischer watchdog.

    Auch die Abhängigkeiten für einen Service zu definieren ist imho logisch und anwenderfreundlich.

    Also ich bleib jetzt bei systemd ...


    cu,

    -ds-

  • die bei Absturz (der ja nicht vorkommen sollte) automatisch neu gestartet werden.

    systemd ist nicht mal in der Lage das System zuverlässig neu zustarten. Da vertrau ich diesem Krebsgeschwür bestimmt keine kritischen Dienste an.

    A stop service is running Waiting x Minutes /infinite 


    Das gleiche Gilt für Startjobs weil systemd einfach drauf los vermutet welche Hardware es denn brauchen könnte anstelle einfach zu starten (z.b. WLAN nicht verfügbar)


    Abstürze von Programmen/ dem System und im journal ist exakt nichts zu sehen, nirgends.

    Unsinnige aufgeblähte Meldungen die keine Infos liefern. Ein service ssh status liefert ein running. einichbindaskürzestewortwasmireingefallenist status ssh(mal mit und mal ohne .service...weil...is so) liefert 20 Zeilen Blödsinn und hoffentlich grüne schrift.


    So wollten init ersetzen und breiten sich im System aus, wo sie nichts zu suchen haben.


    Wer das ganze Elend nicht nur von mir hören will, findet hier ein Lustiges Twitter-Ding und hier die ganzen fachlichen Sachen.


    Ich durfte heute extra ins Rechenzentrum fahren weil mein Azubi vergessen hat eines der Netzwerkabel einzustecken. Die Kiste hing im Boot

    a Start job is running bla bla 7h 15m /infinite - weil ein beknacktes Kabel fehlte, welches 0 mit dem Systemstart zu tun hat. Nö, systemd macht alles einfacher und besser und stabiler. Fürn Arsch.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Na ganz so krass ist es ja nun auch nicht.


    das liefert durchaus sinnvolle Werte, oder nicht?

    Zitat

    pi@pi-lcurr:~ $ service ichbindaskürzestewortwasmireingefallenist status ssh

    ● ichbindask\xc3\xbcrzestewortwasmireingefallenist.service

    Loaded: not-found (Reason: No such file or directory)

    Active: inactive (dead)

    pi@pi-lcurr:~ $



    und das sind bei mir drei Zeilen, nicht 20 ;)


    cu,

    -ds-

  • mit ichbindaskürzestewortwasmireingefallenist meine ich sytemctl (weil sysctl ja schon weg war). ;) Das tippt sich schon scheisse und man kann es nicht sofort autokompleten. Wie immer gilt bei mir - Übertreibung macht anschaulich. Aber was will man von dem Mann der Pulseaudio verbrochen hat auch erwarten. ;)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • ich kann z.B. services definieren, die bei Absturz (der ja nicht vorkommen sollte) automatisch neu gestartet werden.

    Auch die Abhängigkeiten für einen Service zu definieren

    Das, finde ich, sind wirklich zwei sehr nützliche Features. Letzteres ist zumindest besser als ein sleep 10 in der rc.local, und dann hoffen, dass das Netzwerk es schafft :fies:

    liefert 20 Zeilen Blödsinn und hoffentlich grüne schrift.

    Das kann ich sehr gut nachvollziehen, der Grund, WARUM ein Service nicht läuft, wenn dem mal so ist, ist (für mich) nicht immer sofort ersichtlich.

    So wollten init ersetzen und breiten sich im System wo sie nichts zu suchen haben.

    Auch das ist (vermutlich) berechtigte Kritik. Software unnötig aufblähen ist fast nie gut, besonders wenn man sie bei vielen Usern im System verankert.


  • Das, finde ich, sind wirklich zwei sehr nützliche Features.

    Eine Schwalbe macht noch keinen Sommer. Aber ja, nützliche Features. Da es vorher Jahrzehnte auch ohne ging, für mich kein Grund zu wechseln



    Software unnötig aufblähen ist fast nie gut

    Krebsgeschwür trifft es ganz gut.


    serveimage?url=https:%2F%2Fzdnet4.cbsistatic.com%2Fhub%2Fi%2Fr%2F2014%2F10%2F04%2Fe11926d6-4be6-11e4-b6a0-d4ae52e95e57%2Fresize%2F770xauto%2Feb4f70bd27549d4fea66181ddf7f4fc2%2Fsystemd-components.png&sp=72c4f327ddfaf5081beeb06f43047e9c


    und das Debian da so blindlings mitgezogen ist, ärgert mich wirklich. Und es hört ja da nicht auf: Wir konfigurieren ja auch statische IPs in ner Datei names dhcpd.conf. Ein vollkommen logischer und nachvollziehbarer Schritt. Denn diese beiden Sachen sind synonym zu verwenden :wallbash:.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Naja ... ich denke, da sind auch noch konzeptionelle Fallstricke drin, die die Jungs nicht von Anfang an bedacht haben (und das ist imho durchaus menschlich, dass bei so einem komplexen System wie einer Linux Distribution auch mal was übersehen oder vergessen wird).


    Software unnötig aufblähen ist fast nie gut, besonders wenn man sie bei vielen Usern im System verankert.

    Aktuelles Beispiel dazu: Chrome Browser unter Windows ...

    (wenn sich die erste Aufregung gelegt hat denkt niemand mehr darüber nach ... und man kann in aller Ruhe weitere "Features" einbauen ...)

    Aber das gehört hier nicht her.


    cu,

    -ds-

  • Ich durfte heute extra ins Rechenzentrum fahren weil mein Azubi vergessen hat eines der Netzwerkabel einzustecken. Die Kiste hing im Boot

    a Start job is running bla bla 7h 15m /infinite - weil ein beknacktes Kabel fehlte, welches 0 mit dem Systemstart zu tun hat. Nö, systemd macht alles einfacher und besser und stabiler. Fürn Arsch.

    Ach, und wenn das System per SysVinit gestartet worden wäre, hätte es ohne Kabel einen Netzwerkconnet bekommen?

    Oder hättest du auch hinfahren müssen.


    Im übrigen lag das wohl eher an einer falsch konfigurierten Einstellung. Denn natürlich kann man auch beim Systemd das so einstellen, dass er nach einer definierten zeit aufhört zu versuchen, diesen Dient zu starten.

    Practical systemd
    Here is what happens on a stock Arch Linux system, powered by systemd, when a non-root user tries to restart the system:

    Bei dir dürfen "non-root" User SysVinit-Systeme so einfach neu starten?

    BZW:

    Wer Müllkonfiguriert, bekommt Müll geboten.

  • Ach, und wenn das System per SysVinit gestartet worden wäre, hätte es ohne Kabel einen Netzwerkconnet bekommen?

    Oder hättest du auch hinfahren müssen.

    Ach, wenn man doch alles lesen würde und nicht nur das was man lesen will. Ich schrieb ein Netzwerkkabel, nicht das Netzwerkkabel


    Bei dir dürfen "non-root" User SysVinit-Systeme so einfach neu starten?

    *sigh* . Die Kaffemaschine ist kaputt und ich muss schlechten Filterkaffee trinken, deswegen erspar ich mir hier weitere Bemerkungen. Hier soll eigentlich nur sichtbar gemacht wie "sinnvoll" systemd seine User über ein Fehlverhalten informiert. nämlich schlecht bis gar nicht.

    Im übrigen lag das wohl eher an einer falsch konfigurierten Einstellung

    Nö, das ist das Standardsetting und das ist schlicht Müll. Ist aber typisch für systemd jünger - Es ist schlicht falsch konfiguriert. Wenn ich ein frisches System installiere und es funktionieren nicht mal Basisfunktionen (wie das starten, was die Hauptaufgabe von systemd sein sollte) ootb, ist das natürlich kein Problem - Alles nur falsch konfiguriert. :shy:.


    ohne eine Idee von Webdesign

    Form follows Function, nicht anders rum. Ich kann in kürzester Zeit über den Text rattern und Informationen erfassen und bewerten (wie bei bei wikipedia). Da brauch ich kein hübsches Web 8.0 Interface. Wer Manpages mag, muss das einfach mögen ;)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • dbv nö, ich mag mag manpages ;)

    Aber wenn allo so denken würden, wäre ich meinen Job in großen Teilen los...

    Lies mal nen Wikipedia-Artikel ganz ohne Stylesheets. Was so ein bisschen CSS alles ausmachen kann :fies:


    Es redet ja keiner von Bleeding-Edge Technologie, aber ein kleines Stylesheet ist im Jahr 2018 schon angebracht. Natürlich gilt immer noch form follows function, aber gerade bei Textlastigen Seiten kann man sich da Gedanken über Typografie, Whitespace, Zeilenlängen, Kontrast und Farbe etc machen.

    Nicht alles immer gleich verfluchen...

  • Wir konfigurieren ja auch statische IPs in ner Datei names dhcpd.conf.

    Auch wenn ich viele deiner Kritikpunkte teile, aber wäre der logische Weg das Netzwerk unter systemd zu konfigurieren nicht ohnehin systemd-networkd/-resolvd anstellle dhcpd.conf?

  • Mein Netzwerk wird in /etc/network/interfaces konfiguriert ;). Welchen abstrusen Weg systemd da auch immer gehen mag, durchdacht wird es nicht sein. :fies:

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Hallo,


    dbv : dann bete mal jeden Abend fleißig, dass deine Distro nicht auf Netplan umstellt ;-)


    Ich habe mich ja für div. Wikiartikel bei ubuntuusers.de mit systemd beschäftigt und ich muss sagen, dass in seiner Gesamtheit schon ziemlich durchdacht ist. Und natürlich komplex, weil es viel kann. Aber z.B. finde ich für mich z.B. Service Units viel einfacher zu verstehen und schreiben als Start-/Stop Skripte für SysVInit oder Upstart.


    Was mich bei Raspbian (im Vergleich zu Ubuntu) stört ist, dass das Logging komisch konfiguriert ist. Also Ubuntu (und AFAIK auch andere Distros) loggen viel mehr in Journal als Raspbian. Was ja der Schonung der SD-Karte geschuldet sein mag.


    Aber ganz realistisch: systemd ist der Standard. Mit Ubuntu 15.10 hat ja die letzte "große" / "relevante" Distro auf systemd umgestellt. Man kann sich zwar in ein kleines, gallisches, aktuell systemd-freies Dorf zurück ziehen, aber das bringt auf dauert auch nichts.


    Gruß, noisefloor

  • Aber ganz realistisch: systemd ist der Standard. Mit Ubuntu 15.10 hat ja die letzte "große" / "relevante" Distro auf systemd umgestellt. Man kann sich zwar in ein kleines, gallisches, aktuell systemd-freies Dorf zurück ziehen, aber das bringt auf dauert auch nichts.

    Aber kein guter und vor allem kein notwendiger. init war nie kaputt und muss erst recht nicht durch diesen Murks ersetzt werden. If it ain't broke - don't fix it. War früher auch mal die Einstellung von Debian. Aber, das ist wirklich das gute an Linux - es gibt für jeden Topf seinen Deckel. Ich hab fast alle Pi auf Devuan umgezogen. Traumhaft...ich könnte vor Freude weinen während er bootet. Während mein Octoprint-Pi (der einzig verbliebene raspbian pi )noch bootet und auf wer weiß was wartet, sind die anderen Kisten erstmal an. Ich werde bei Gelegenheit auch ein Tutorial schreiben wie man das einrichtet.


    Also Ubuntu (und AFAIK auch andere Distros) loggen viel mehr in Journal als Raspbian.

    Wenn was kritisches stirbt -steht es trotzdem nirgends. Journal hin oder her.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Hallo


    dbv :


    Zitat


    Aber kein guter und vor allem kein notwendiger. init war nie kaputt und muss erst recht nicht durch diesen Murks ersetzt werden.

    Also wenn ich mich nicht stark irre, wollte Debian doch so wie so von SysVInit weg... Da gab es doch AFAIK eine interne Abstimmung zwischen Upstart und systemd, systemd hat gewonnen. Was dann quasi auch der Tod von Upstart war.


    Gruß, noisefloor

  • Ich finde es absolut genial, weil man damit phänomenale Möglichkeiten hat und richtig gute Kontrolle über seine Prozesse bekommt... weitaus besser, als das mit sysvinit jemals möglich war.


    systemd ist nicht mal in der Lage das System zuverlässig neu zustarten. Da vertrau ich diesem Krebsgeschwür bestimmt keine kritischen Dienste an.

    A stop service is running Waiting x Minutes /infinite

    Hast Du Dich nie gefragt, dass das vielleicht gar kein Systemd-Problem ist, sondern ein reines Customizing-Problem, verursacht durch den verantwortlichen Admin? Mich erinnert das ziemlich deutlich an einen Schaltwagenfahrer, der regelmäßig seinen Automatik-Dienstwagen versemmelt, weil er mit 2 linken Füssen und dem einen fehlenden Pedal nicht klarkommt und dann dem Automatik-Getriebe die Schuld gibt. Das ist doch echter Blödsinn. Und mich erinnert das an die frühen Diskussionen, als die typische Topdown-Programmierung mit C durch die eine eventgesteuerte objektorientierte Programmierung mit C++ abgelöst wurde. Was haben die Leute damals darauf geschimpft... und dabei war objektorientierte Programmierung faktisch der geilste Fortschritt zur damaligen Zeit mitte der 80er.


    Das gleiche Gilt für Startjobs weil systemd einfach drauf los vermutet welche Hardware es denn brauchen könnte anstelle einfach zu starten (z.b. WLAN nicht verfügbar)

    Nein, das ist falsch... eine absolut falsche Erwartungshaltung. Systemd vermutet überhaupt nix. Und systemd hat überhaupt nix damit zu tun oder ist dafür veranwortlich, dass irgendwelche im Kopf des Admins bestehenden imaginären Abhängigkeiten während einer parallel ablaufenden Startphase eingehalten werden. Was hat denn systemd mit der Verfügbarkeit vom WLAN zu tun, wieso sollte sich systemd überhaupt darum scheren? Es ist alleinig Sache des Admins, seine eigenen Jobs sachkundig via Service-Units und unter Berücksichtigung der von ihm festgelegten Abhängigkeiten in den Start-Prozess einzureihen... und das geht mit systemd absolut genial einfach.


    Ich verstehe gar nicht, was da immer von systemd erwartet wird... es soll doch nur Prozesse starten... und zwar nach meinen Abweisungen. Und wieso ist systemd verantwortlich, wenn ich nicht imstande bin, saubere Anweisungen für einen parallelen Start von Prozessen zu formulieren?


    Meine Meinung dazu ist, dbv , lösche einfach ALLE initd-Scripte, die Du noch hast... wirklich alle... einschließlich dieses völlig überflüssigen /etc/init.d/networking. Richte dann für alle zu startenden Jobs passende Service-Units ein, mit entsprechenden Statements für zeitliche und sachliche Abhängigkeiten und alle Deine Probleme sind gelöst. So war es zumindest bei mir. Das krampfhafte Festhalten an die alten sysvínit-Scripte, die unter systemd mehr oder weniger zeitlich zufällig ausgeführt werden, ist imho eine Garantie für Probleme... deshalb, weil sie im Kompatibilitäts-Modus gestartet werden... und da fehlen schlichtweg saubere Angaben zu Abhängigkeiten zu anderen gleichzeitig gestarteten Prozessen. Gibt es diese Angaben für die Startphase des Prozesses, passieren solche "stop-service"-Effekte beim Shutdown definitiv nicht mehr.


    Systemd startet alles mehr oder weniger gleichzeitig, ohne darauf zu warten, dass irgendein Job fertig ist oder von irgendwas anderes abhängig ist. Das ist so gewollt und das ist so genial... das ist ganz einfach "intended working", genau so wie das "Nicht-Schalten-Müssen" ebenfalls "intended working" beim Automatik-Getriebe eines Autos ist. Und bei Problemen damit ist imho nicht das Auto schuld.


    j.m.2.c.

  • Beitrag von ThomasL ()

    Dieser Beitrag wurde vom Autor gelöscht ().
  • Das kann ich sehr gut nachvollziehen, der Grund, WARUM ein Service nicht läuft, wenn dem mal so ist, ist (für mich) nicht immer sofort ersichtlich.

    systemd bietet absolut geniale Möglichkeiten zur Fehlersuche, bis hin zur grafischen Anzeige von Abhängigkeiten. Ich habe hier z.B. einen eigenen Prozess "Netfilter", den systemd mir zur Anzeige der sachlichen Abhängigkeiten folgendermaßen anzeigen kann:

    Job

    Code
    1. Color legend: black = Requires
    2. dark blue = Requisite
    3. dark grey = Wants
    4. red = Conflicts
    5. green = After

    Oder zur zeitlichen Kontrolle von Abhängigkeiten hier mein Prozess "mountctl.service", der aufs Netzwerk warten muss... was er hier erfolgreich tut:

    Job


    Ich glaube, besser kann man das kaum noch machen... man muss nur wissen, wie man systemd bedient.

    Auch das ist (vermutlich) berechtigte Kritik. Software unnötig aufblähen ist fast nie gut, besonders wenn man sie bei vielen Usern im System verankert.

    Auch das ist imho eine völlig unzutreffende Unterstellung. Zeig mir eine Stelle, auf die die Festellung "aufgebläht" zutrifft. Systemd bringt doch gar nicht nur ein Programm mit, was alles kann, sondern etliche Programme für jeweils eine Aufgabe, die optimal in ein geniales Gesamtkonzept integriert sind. Ich kann da überhaupt nichts falsches dran erkennen. Im Gegenteil, das ist doch endlich mal ein richtig wichtiger Schritt in die Zukunft. Für mich ist sysvinit aus heutiger Sicht einfach nur noch ein lahme Ente mit nur einem Flügel, genau so wie es ist mit sudo und den Prothesen "gksudo" und "ksudo".... auch das sind nur noch Krücken. Für mich ist klar, dass man unter systemd Probleme hat, wenn man an dem alten Scheiss festhält... aber dafür systemd verantwortlich zu machen halte ich für einigermaßen unsachlich.

  • Ich glaube, besser kann man das kaum noch machen... man muss nur wissen, wie man systemd bedient.

    Absolut... ich kann grundsätzlich mit systemctl umgehen, Service Units erstellen und verwalten, aber allzuviel habe ich mich damit auch nicht beschäftigt, unter anderem, weil es fast immer reibungslos läuft. Am Laptop/Desktop hatte ich noch nie Probleme mit Systemd, am Server auch nicht, am Raspi manchmal (hier wird natürlich auch am meisten experimentiert).

    Auch das ist imho eine völlig unzutreffende Unterstellung. Zeig mir eine Stelle, auf die die Festellung "aufgebläht" zutrifft.

    Mein Eindruck nach dem Bild aus #7 ;)


    Wie gesagt, bei den Startdiensten bin ich relativ fit, was Systemd sonst noch so werkelt scheint so gut zu funktionieren, dass ich es gar nicht merke.


    Aber unter anderem deswegen wollte ich mir auch mal ein paar Meinungen einholen!