Hello, Guest the thread was called4.5k times and contains 47 replays

last post from nonic at the

systemd: Was ist so schlecht daran, was ist vielleicht gut?

  • Im Nachbarthread hat sich jemand über "systemd-bashing" beschwert. Ich nehme das hier mal zum Anlass, ernsthaft darüber zu schreiben -- dann kann ja eventuell darüber diskutiert werden.


    Systemd hat de facto (da die meisten Distributionen mitziehen) die Rolle des "Standard-Init-Systems" auf Linux übernommen. Ich beginne mal damit, was ein Init-System auf Unix und verwandten Systemen (im Folgenden rede ich einfach von Unix, auch wenn das nicht ganz korrekt ist) ist, es folgt ein kleiner Exkurs:


    Wenn ein Betriebssystem startet, lädt der Bootloader zunächst den Kernel (auf Unix meistens ein Monolith, aber sauber vom restlichen System getrennt). Der Kernel läuft mit besonderen Privilegien, hat als einzige Komponente die Möglichkeit, direkt Hardware zu prorgrammieren, und hat ein paar wichtige Aufgaben: Prozesse und Speicher verwalten, Kommunikation zwischen Prozessen ermöglichen, Hardware durch Treiber und einheitliche Schnittstellen abstrahieren (wie z.B. Dateisysteme für Datenträger) -- die Liste ist verkürzt, das sind aber IMHO die wichtigsten Punkte. Ein Prozess ist ein Programm, das im Userspace (d.h. ohne die Kernel-Privilegien und mit virtualisiertem Speicher) läuft. Ohne Prozesse kann man ein System nicht nutzen, der Kernel selbst tut nichts, was für einen Anwender nützlich wäre. Selbst die Eingabe von Befehlen wird in einem Userspace-Prozess implementiert. Ein Prozess kann durch Aufruf entsprechender Kernel-Funktionen einen weiteren Prozess als "Kind" starten und ist dann dafür verwantwortlich, diesen zu überwachen und bei Bedarf (in der Regel wenn der Kindprozess endet, aber auch bei Fehlern/Abstürzen) wieder entfernen zu lassen. Ein beendeter Prozess, der nicht entfernt wird, ist ein "Zombie" -- die nötigen Daten sind im Kernel noch vorhanden, aber der Prozess ist nicht lauffähig, ein "Untoter" eben. Wenn ein Prozess also abstürzt oder auch normal endet, wird er normalerweise von seinem Elternprozess entfernt. Wenn er selbst Kinder hat, "erbt" der Elternprozess diese. Der Absturz eines Userspace-Prozesses kann dem System normalerweise nichts anhaben -- für den User zwar ärgerlich, aber das System neu starten muss er nicht, andere Prozesse laufen normal weiter.


    "Kritisch" ist also der Kernel selbst. Wenn der abstürzt, ist das System nicht mehr lauffähig, allerlei schlimme Dinge könnten passieren. Wenn der Kernel stabil läuft, ist das System stabil. Allerdings startet beim Bootvorgang ja nur der Kernel, irgendwie muss das restliche System in Gang kommen -- und hier kommt das Init-System ins Spiel. Zunächst einmal gibt es auf jedem Unix-System ein Programm namens "init" -- das ist das einzige Programm, das direkt vom Kernel gestartet wird. Das hat zur Folge, dass alle anderen Prozesse im System direkt oder indirekt Kindprozesse von "init" sind. Damit ist init selbst auch eine kritische Komponente -- sollte init jemals abstürzen kann das System nicht vernünftig weiterlaufen, weil es keinen anderen Prozess mehr gibt, der die ganzen Kindprozesse erben könnte.


    Um nun die ganzen anderen Prozesse zu starten, die den Computer "benutzbar" machen, startet init in einem "klassischen" Init-System ein Shellscript. Auf ganz alten Systemen war das wirklich nur ein einzelnes Script (/etc/rc), vergleichbar mit der AUTOEXEC.BAT von MS-DOS oder der startup-sequence von AmigaOS. Heute gibt es ganze "rc-Systeme", bei denen auf konfigurierbare Art pro zu startendem Prozess ein eigenes Script ausgeführt wird (ein "init-script"), die besseren dieser Systeme können das nicht nur in einer festen Reihenfolge sondern auch anhand konfigurierbarer Abhängigkeiten, so dass voneinander unabhängige Prozesse parallel gestartet werden können (für kürzere Boot-Zeiten). Jedenfalls ist die ganze Logik zum starten in Shellscripts abgelegt, "init" weiß davon nichts. Das hat einen großen Vorteil: "init" ist klein und überschaubar, das Risiko für Bugs in init ist gering. Nach dem Startvorgang hat init nur noch die Aufgabe, beendete Prozesse abzuräumen falls es kein anderer Elternprozess tut -- diese Aufgabe ist aber essentiell wichtig für die Stabilität des gesamten Systems.


    Diese Zusammenfassung ist bewusst unvollständig, alles andere würde hier den Rahmen sprengen.


    Seit einiger Zeit gibt es alternative "moderne" Init-Systeme (und systemd ist eines davon), bei denen auf Shellscripts verzichtet wird. Das hat zunächst einen Performance-Vorteil -- spezialisierte Konfigdateien lesen ist sehr viel weniger komplex als das was eine Shell, als generischer Befehls-Interpreter, tut. Man hat also zunächst die Möglichkeit, den Systemstart weiter zu beschleunigen -- etwas, was Desktop- (oder Notebook-) User durchaus interessiert. Der Nachteil ist, dass neu implementiert werden muss. Entweder ein spezialisierter Prozess zum starten, oder direkt in "init" (wie es systemd tut. Das "init" dort ist zwar prinzipiell modular aufgebaut, läuft aber alles in einem Prozess). Mehr Code in "init" bedeutet ein höheres Risiko für Bugs.


    Kommen wir nun endlich zum Kern, was meiner Meinung nach schlecht an systemd ist. Es ist schlicht zu viel Komplexität. systemd versucht, neben der Kernaufgabe von "init", gleich noch eine Vielzahl anderer Aufgaben zu übernehmen, z.B.:

    • "Respawn" für unerwartet beendete Prozesse: Es kommt vor, dass Services/Daemons "buggy" sind und auch mal unerwartet aussteigen. Dann ist es sicher ein nettes Feature, wenn sie automatisch neu gestartet werden. Das ist aber keine Kernaufgabe von "init", dafür gibt es dedizierte Tools, denn es steckt einiges an Komplexität drin. So muss zum Beispiel konfigurierbar sein, ob ein bestimmer Prozess neu gestartet werden soll. Außerdem muss man wiederkehrenden Fehlern vorbeugen, so dass ein ständig abstürzender Prozess nicht ständig neu gestartet wird und damit Systemresourcen frisst.
    • Start von Benutzerprozessen: "init" startet normalerweise Systemprozesse. So etwas wie Services/Daemons, oder auch einfach nur ein Login-Programm (für Konsole oder grafische Oberfläche) -- die werden alle als "root", also mit administrativen Rechten gestartet. Wenn ein User eigene Prozesse automatisch gestartet haben will ist auch das normalerweise Aufgabe eines anderen (von "init" gestarteten) Tools. Denn auch da steckt Komplexität drin, zum Beispiel auch Sicherheits- und Berechtigungsfragen.
    • Logging: Ein Unix-System hat normalerweise einen zentralen Logging-Mechanismus. Ein spezieller Daemon nimmt von anderen Prozessen Log-Messages entgegen und sortiert diese nach bestimmten Regeln in verschiedene Logfiles ein. Wie man auf die Idee kommt, diese Funktion in "init" zu integrieren, ist mir völlig schleierhaft....
    • Session-Verwaltung für grafische Benutzerlogins: Ein sehr komplexes Thema: Wenn man lokal am eigenen PC als User eingeloggt ist, erwartet man, bestimmte Dinge tun zu können, wie den Rechner herunterzufahren oder schlafen zu legen. Wer remote eingeloggt ist sollte das ziemlich sicher nicht dürfen. Dafür gibt es alte Tools wie "polkit/consolekit", die schon ihre Problemchen haben. Die entsprechende Funktionalität in "init" einzubauen verspricht ein etwas einfacheres/schlüssigeres Gesamtdesign, macht aber wieder "init" selbst sehr viel komplexer.

    Die Liste ist fortsetzbar.


    Neben dem oben ausführlich erklärten Risiko für die Systemstabilität, wenn "init" sehr komplex ist, hat das auch aus Benutzersicht Nachteile. Jeder, der sich einmal eingehender mit Unix beschäftigt hat, kann mit Shellscripts umgehen. Fehlern in einem "klassischen" Init-System mit minimalem "init" Programm und Scripts zum starten der Prozesse kann ein erfahrener User auf den Grund gehen. Hat man dagegen nur Konfigurationsfiles in einem eigenen Format, ist es zuweilen schwierig nachzuvollziehen, was schiefgeht und warum. Richtig schlimm wird es IMHO beim Logging. Logging-Systeme auf Unix haben immer Textdateien geschrieben (überhaupt gehört das menschenlesbare Textfile an vielen Stellen zur Unix-Philosophie), was den unschätzbaren Vorteil hat, dass man diese eigentlich immer überall lesen, auswerten und weiterverarbeiten kann. Tools für Textfiles gibt es zuhauf. Systemd dagegen loggt in einem eigenen Binärformat. Wenn man nicht zusätzlich in Textfiles loggt, ist man auf die Tools von systemd angewiesen -- eine Einschränkung, und natürlich auch ein Risiko; wenn diese Tools einmal beschädigt sein sollten, kann man nicht einmal mehr Logs lesen.


    Ist alles schlecht? Meiner Meinung nach in der Umsetzung schon. Die Grundidee, Shellscripting im Init-System zu ersetzen, hat sicher ihre Berechtigung. Insbesondere bei dem früher auf Linux verwendeten SYSV-Init sind die Shellscripte teils riesig und damit selbst fehleranfällig (allerdings ist dann nur der Start eines Dienstes kaputt, nicht das ganze System). Es gibt bessere Systeme wie z.B. das auf FreeBSD, bei dem die Scripts für einen Dienst in der Regel sehr klein und überschaubar sind. Trotzdem hat man immer den Overhead der Shell, die die Scripts parsen muss. Ein schnellerer Start des Systems lässt sich ohne Shellscripts sicher erreichen. Neben systemd gibt es andere Init-Systeme, die ebenfalls auf Shellscripts verzichten.


    Das Grundproblem, meiner Meinung nach, ist, dass systemd viel zu weit geht. Eigentlich sagt es schon der Name, die "Vision" ist ein(!) Daemon zur Verwaltung des Systems. Als ein Unix-Leitsatz gilt nicht umsonst "one job, one tool", das ist besser für die Stabilität und flexibler und durchschaubarer für den User. Systemd erledigt ganz viele Jobs in einem einzigen Tool, und das noch dazu in einem für die Systemstabilität essentiellen Prozess.

  • Ich finde systemd auch viel zu komplex.


    Andererseits nutze ich es gezwungenermaßen, weil ich 1. wenig Ausweichmöglichkeiten habe und 2. es mich an die Leute erinnert, die unter XP immer die klassische Startleistenansicht aktivierten.

    Ich sagte damals schon zu denen: "Gewöhnt euch einfach daran. Irgendwann wird das nicht mehr möglich sein und ihr guckt dann dumm."

    Und so kam es ja dann auch.


    Ein init-System abseits der breiten Masse mag zwar möglich und in gewissen Bereichen sinnvoll sein aber sobald ich moderne 3rd-Party Software (z.B. Turboprint) verwende, wird einfach stillschweigend systemd vorausgesetzt. Muss man zwar nicht mögen, ist aber leider so.

  • Also ich finde z.B. `journalctl -f` ist das neue Kommando des Jahrzehnts. Auch an den Rest kann man sich gewoehnen. Ist definitv nicht schlechter als SysV Init.


    Wovon ich ganz und gar nicht ueberzeugt bin, ist das neue homed. Weil fuer da wo man es braucht (auf Servern mit mehreren Benutzerkonten) kann man es nicht benutzen (weil kein SSH moeglich, und UID/GID Abgleich falsch rum geloest), und auf persoenlichen Rechnern ist es schlicht unnoetig, weil 99,9% dieser nur einen Benutzer haben.

  • Huh, so viel Text, und (mit Verlaub) so viel daneben.


    Es geht überhaupt nicht darum, bash-Skripte zu ersetzen "weil sie langsam sind".


    Der Bootup-Prozess ist/war nicht langsam, weil bash-Skripte langsam wären (duh! Als wäre "bash" jetzt ein schwergewichtiger Prozess), sondern insbesondere weil sysvinit kein brauchbares Dependency-Management hat und alles nacheinander gestartet wird. Aber z.B. das Initialisieren des Netzwerks (DHCP...) dauert mehrere Sekunden, in denen dann gar nichts passiert, obwohl schonmal andere Services (teilweise) initialisiert werden könnten.


    Um das parallele Starten kümmert sich systemd und kann da auch noch andere Tricks anwenden, z.B. Dienste erst dann starten, wenn sie (über dbus/Sockets) tatsächlich angefordert werden. (x)inetd hat das früher ansatzweise gemacht, so richtig schlecht und langsam und unflexibel, deswegen haben's auch alle gehasst und keiner wirklich benutzt nach den 80ern. systemd macht's besser.


    Die Dependency-Sache wurde auch nicht nur von systemd angegangen; auch (mindestens) Ubuntu hatte mit Upstart eine eigene (skript-basierte) Lösung am Start, und Debian hatte meine ich auch was eigenes. Sowohl Ubuntu als auch Debian haben ihre eigenen Lösungen zugunsten von systemd aufgegeben. Ganz klar, dass bei Ubuntu und Debian alles Deppen sind, die keine Ahnung haben... :/


    Dann gibt's noch weitere Realitäten, die sysvinit ignoriert, z.B. was ist denn, wenn man ein neues Netzwerkinterface anstöpselt oder Hardware, die aufwendig initialisiert werden muss (z.B. Firmware hochgeladen werden muss) oder Hardware, die nur mit einem bestimmten Daemon läuft, der ansonsten aber sinnlos ist (z.B. ein USB-Bluetooth-Dongle und sein bluetoothd). Alle diese Sachen wurden früher irgendwie gefrickelt, mit eigenen init-Skripten in eigenen Frameworks, die FURCHTBAR waren.


    Und letztendlich bündelt systemd auch ganz abseits von init-Dingen etliche Dienste, die früher de facto ungewartetes Gefrickel waren (z.B. die hostname-Utilities oder das Durcheinander an ntp-Clients).


    Und wenn man sich mal ein klein wenig mit systemd auseinandersetzt, gibt es einem auch bessere Kontrolle über den Rechner, denn im Gegensatz zu "oh wo kommt denn dieser Prozess her? init? udev? Eigener obskurer Start-Daemon?" gibt's bei systemd recht brauchbare Tools, sich einen Überblick zu verschaffen, und es ist an vielen Stellen auch schlicht und ergreifend benutzerfreundlicher, z.B. ist die Ausgabe von "systemctl status networking" zweifellos hilfreicher (sogar mit Fließtext-Kommentar!) als das kurze "running", das "service" dazu früher ausgab.


    Lange Rede kurzer Sinn, systemd ist sicher nicht komplett Gold und hat Bugs und Poettering ist ein schwieriger Mensch, aber tut euch einfach einen Gefallen und lest wenigstens die Basics, zum Beispiel

    http://0pointer.de/blog/projects/systemd.html

  • Ebenfalls "mit Verlaub" -- erstmal lesen bevor man was raushaut hilft auch.


    Ich habe explizit nicht von dem auf Linux verbreiteten sysv-init geredet, denn das ist ein eher schlechter Vertreter seiner Gattung. Klassische Init-Systeme mit Shellscripten existieren schon lange auch in wesentlich besseren Varianten, mit Abhängigkeiten (was so auch in meinem Eingangsposting steht) und der Fähigkeit, unabhängige Prozesse parallel zu starten. Es bleibt also in der Tat nur der Overhead der vielen Shell-Aufrufe (übrigens ist Shell auch nicht gleichbedeutend mit bash, bash ist in der Tat langsamer als so manche minimale bourne-Shell, sollte deshalb auch eher nicht vom Init-System verwendet werden) -- jeder Prozessstart kostet Zeit, und das Parsen eines Shellscripts ebenfalls. Das ist alles, was gegenüber einem guten shell-basierten Initsystem an Performance herauszuholen ist.


    Der eigentlich wichtige Punkt ist, dass systemd viel zu viel in den init-Prozess packt. Man kann sicher einige Features richtig gut finden, im init-Prozess liegen sie aber an der falschen Stelle. Diesen wichtigsten Aspekt hast du vollständig ignoriert.

  • Ich schrieb ja auch bereits, dass Performance nur ein kleiner Teil der ganzen Geschichte ist, und dass es andere skriptbasierte Lösungen für das Dependency-Problem gibt, die wenigstens von Ubuntu und Debian wieder aufgegeben wurden.


    Was packt denn systemd Deiner Meinung nach in den init-Prozess, was da nicht reingehört? So mal ganz konkret?

  • ich habe mich sowohl mit Linux "vor systemd" und mit den aktuellen Varienten "mit systemd" beschäftigt und sehe bei systemd mehr Vorteile als Nachteile im Vergleich zum klassischem Linux-init. aber systemd ist nicht nur init und sollte es auch nie sein sodern viel mehr. Und gerade DAS sind die Stärken, die systemd hat.


    1570 hat die Details von den IMHO genialen Features sehr gut auf den Punkt gebracht.


    Ich kann Euch einen Podcast von ChaosRadio empfehlen, in dem Lennart Poettering (einer der Entwickler) von systemd sehr gut und nachvollziehbar erklärt, wie und warum systemd entstanden ist.


    mir persönlich gefällt gerade das sehr leistungsfähige und gut konfigurierbare Logging (/etc/systemd/journald.conf).

    jounalctl -b1 -p0 -p1 -p2 -p3

    ... zeigt mir z.B. von der vorherigen Sitzung alles an, was shice gelaufen ist (und das nicht nur vom init).

    Also ich finde z.B. `journalctl -f` ist das neue Kommando des Jahrzehnts. Auch an den Rest kann man sich gewoehnen.

    Volle Zustimmung !! :thumbup:

  • aber systemd ist nicht nur init und sollte es auch nie sein sodern viel mehr. Und gerade DAS sind die Stärken, die systemd hat.

    Und gerade DAS ist auch das Problem. Nicht die Features, die es bietet. Aber deren Umsetzung in "init". Das meiste davon müsste (und sollte!) nicht in "init" sein.


    Ein weiterer Aspekt, den ich noch vergessen habe: Dadurch, dass all das in einem Tool zusammengefasst ist, wird es schwierig, ein anderes Init-System einzusetzen. Das auf Linux verwendete sysv-init war wirklich schlecht, aber es hätte genug Alternativen (mit klassischem Aufbau) gegeben.

  • Versucht doch bitte mal einer von euch ein Start-Script zu schreiben, das genau nach einem anderem Script, aber definitiv vor einem anderem startet.

    Da sag ich mal, viel Spass dabei :)


    Weitere Negative Punkte sind. Es ist nicht nach dem Kiss-Prinzip gestrickt (wurde hier aber schon mehrmals genannt), was mich total abtörnt. Und in der Vergangenheit hat der nette Projektleiter einfach Bugreports zugemacht und behauptet, sie seien gelöst, obwohl nichts passiert ist. Ob er das noch macht, weiß ich natürlich nicht, spricht aber nicht gerader für ihn.


    Die Vorteiel, sind meiner Ansicht nach eher dünn. Schnelleres Booten, supa. Macht mein OpenRC ebenso. Vielleicht nicht in 3 Sekunden, aber mit 6 hält sich das in Grenzen.

    Besseres Syslog? Naja, gabs auch für den alten Sysloger einige Ersatzmöglichkeiten und ob ich im Log echt die 5 Sekuden-Nachkommerstelle brauche???? Oder nen Binär-Format???

    Und den Rest ignoriere ich mal, da sehe ich gar kein Vorteil.

  • zrs1 Die vier Spiegelstriche sollen Beispiele sein, was in PID 1 nicht reingehört?


    Benutzerprozesse: PID 1 startet auch bei systemd keine Benutzerprozesse, das machen separate Instanzen (schau Dir z.B. die pstree-Ausgabe an).


    Logging: PID 1 macht auch mit systemd kein Logging, das macht systemd-journald, ein separater Prozess.


    Session-Verwaltung: PID 1 macht das nicht, sondern systemd-logind, ein separater Prozess.


    "Respawn" kann man drüber diskutieren. Die meisten anderen Systeme (supervisord, runit etc.) machen das genauso wie systemd und die Annahme, dass sich Dienste nur im Fehlerfall beenden, ist ja schon die erste Krux; das tun z.B. inetd-konforme Dienste eben NICHT.

  • Aber deren Umsetzung in "init". Das meiste davon müsste (und sollte!) nicht in "init" sein.

    und das macht es für Dich unbenutzbar ? oder unsicher ?


    Ich sehe das so: genau so, wie Hardware sich weiterentwickelt, tut es auch Software. Ich sehe sysemd als Weiterentwicklung.

    Irgendwann muß man sich auch mal von alten Sachen lösen zugunsten von neuen Sachen.

    Und wer es wie die Gallier machen will, nämlich sich gegen die neuen Sachen wehren und an den alten Sachen festhalten will, der kann es doch tun- mit mehr oder weniger Aufwand.

    Linux bietes alles, um sich seine eigene Distri zusammen zu basteln.

    Henning z.B. hat glaub ich ein (z.T. selbst compiliertes !?) ArchLinux mit einem selbst geschriebenen ruby-init - system ... Möglich ist alles, jeder so wie er mag.

    Nur ob das fertige System am Ende des Tages nach all der Arbeit schneller/stabiler/sicherer läuft und besser wartbar ist, ist die große Frage.:whistling:

  • Ja, Kindprozesse, immerhin. Allerdings: Keiner dieser Prozesse funktioniert ohne laufenden systemd init. Sie kommunizieren also alle mit diesem Prozess, und das bedeutet eben, dass sich "init" sehr wohl Komplexität durch diese Features reinzieht (wenn auch zugegebenermaße nicht alles).


    Was du mit dem letzten Punkt sagen willst verstehe ich nicht.

  • und das macht es für Dich unbenutzbar ? oder unsicher ?


    Ich sehe das so: genau so, wie Hardware sich weiterentwickelt, tut es auch Software. Ich sehe sysemd als Weiterentwicklung.

    Irgendwann muß man sich auch mal von alten Sachen lösen zugunsten von neuen Sachen.

    Unsicherer? Vielleicht. Auf jeden Fall potentiell instabiler (die besondere Bedeutung des "init" Prozesses habe ich ja erklärt, damit das nachvollziehbar wird) und schwerer zu durchblicken.


    Es geht hier nicht um alte oder neue Software, ich dachte das wäre auch erkennbar gewesen. Es geht um bewährte Prinzipien, denen auch neuere Software besser folgen sollte.

  • Ich weiß nicht, inwiefern systemd-journald mit PID 1 verquickt ist. Ich vermute, dass sich das in Grenzen hält und es eben nur um Dinge wie die Socket Activation dreht, dass also geloggt werden kann, noch bevor journald oben ist. Das finde ich okay und sinnvoll.


    Insbesondere finde ich es irreführend und nicht fair, was von "systemd macht Logging in PID 1" zu faseln bzw. nahezulegen, wenn das eben NICHT der Fall ist.

  • "Respawn" für unerwartet beendete Prozesse: Es kommt vor, dass Services/Daemons "buggy" sind und auch mal unerwartet aussteigen. Dann ist es sicher ein nettes Feature, wenn sie automatisch neu gestartet werden. Das ist aber keine Kernaufgabe von "init", dafür gibt es dedizierte Tools, denn es steckt einiges an Komplexität drin. So muss zum Beispiel konfigurierbar sein, ob ein bestimmer Prozess neu gestartet werden soll. Außerdem muss man wiederkehrenden Fehlern vorbeugen, so dass ein ständig abstürzender Prozess nicht ständig neu gestartet wird und damit Systemresourcen frisst.
    Start von Benutzerprozessen: "init" startet normalerweise Systemprozesse. So etwas wie Services/Daemons, oder auch einfach nur ein Login-Programm (für Konsole oder grafische Oberfläche) -- die werden alle als "root", also mit administrativen Rechten gestartet. Wenn ein User eigene Prozesse automatisch gestartet haben will ist auch das normalerweise Aufgabe eines anderen (von "init" gestarteten) Tools. Denn auch da steckt Komplexität drin, zum Beispiel auch Sicherheits- und Berechtigungsfragen.

    Sorry Alter, aber das stimmt faktisch nicht, aus diversen manpages:

    Und da gibt es noch viele viele weitere nuetzliche Optionen.


    Logging: Ein Unix-System hat normalerweise einen zentralen Logging-Mechanismus. Ein spezieller Daemon nimmt von anderen Prozessen Log-Messages entgegen und sortiert diese nach bestimmten Regeln in verschiedene Logfiles ein. Wie man auf die Idee kommt, diese Funktion in "init" zu integrieren, ist mir völlig schleierhaft....

    Tja, da schliesse ich mich dem Rat von davor an, mal das Gespraech im CRE mit Poettering zu hoeren. Das macht jede Menge Sinn, was man spaetestens weiss wenn einem einmal ein DDoS die log Partition zum Ueberlaufen gebracht hat. Und das ist nur einer von vielen Gruenden.


    Also die Argumente sind ehrlich gesagt etwas schwach, und anscheinend schlecht recherchiert.

  • Wenn ich das mal aus "Anwendersicht" kommentieren darf..:


    Ich setze alle 5 bis 10 Jahre einen Linux-Server auf und ärgere mich die Platze, dass schon wieder alles anders ist,

    wo ich eigentlich nur genau dasselbe wie vorher haben will, aber zur neuen Hardware passend, und gerne ein wenig

    komfortabler. Im Prinzip ist mir das egal, wie das System startet, aber ich fände es schön, wenn es relativ intuitiv wäre,

    und das war es seit meinem ersten Kontakt in den 90ern schon nicht. Und jedes Mal lerne ich alles wieder neu, aber

    vergebens, denn ich kann mich schon drauf einrichten, es beim nächsten Mal nicht wieder verwenden zu können.


    Das betrifft natürlich nicht nur die Startsequenz sondern z.B. auch SAMBA, das jedes Mal mehr neue Direktiven fordert,

    um in einem heterogenen Netzwerk mit Rechnern im Alter von 0 bis 25 Jahren wie vorher zu funktionieren. :S


    Für mich wäre der Weg zu einem schönen System ein Streamlining aller Configs und Kommandozeilenoptionen

    (keine psychedelischen Lösungen à la procmail.rc.. die sich aber wenigstens nicht verändert hat) und eine saubere Startdatei.