{"id":14073,"date":"2024-02-04T03:39:03","date_gmt":"2024-02-04T02:39:03","guid":{"rendered":"https:\/\/linux-bibel.at\/?p=14073"},"modified":"2024-02-04T19:15:50","modified_gmt":"2024-02-04T18:15:50","slug":"warum-wird-systemd-eigentlich-gerne-schlecht-geredet","status":"publish","type":"post","link":"https:\/\/linux-bibel.at\/index.php\/2024\/02\/04\/warum-wird-systemd-eigentlich-gerne-schlecht-geredet\/","title":{"rendered":"Warum wird Systemd eigentlich gerne schlechtgeredet?"},"content":{"rendered":"\n

Die Einführung von Systemd<\/a> war für so einige Linux<\/a>-Enthusiasten ein vollkommener Umbau von Linux<\/a>, absolut böse – die Reiter der Apokalypse kommen.<\/p>\n\n\n\n

Grundlegend war Systemd<\/a> zu Beginn nur für den Start der Dienste unter Linux<\/a> zuständig – also um ein lauffähiges System zu bekommen. Davor wurde jeder Dienst einzeln gestartet. Dies dauerte natürlich so seine Zeit, Systemd<\/a> startet hingegen mehrere Dienste zur selben Zeit. Schnell wurden Systemd<\/a> jedoch mehrere Funktionen hinzugefügt – etwa die Verwaltung der Logs, man kann damit sein System automatisieren und vieles mehr.<\/p>\n\n\n\n

Warum bezeichnen manche Systemd nun als böse?<\/h3>\n\n\n\n

Unter Linux<\/a> herrscht seit jeher die Philosophie „One task – one tool“<\/em> – also für eine Aufgabe ein Werkzeug. Systemd<\/a> hingegen verwaltet nicht nur eine einzige Aufgabe, sondern viele. Noch dazu kommt: Systemd<\/a> legt die Logs in binäre Datei<\/a>en statt in reine Textdatei<\/a>en – man kann also etwa keinen einfachen Texteditor<\/a> nutzen, um in diese Einblick zu erhalten. Böse, sehr böse.<\/p>\n\n\n\n

Aber Systemd<\/a> ist reine freie Software, deshalb auch im Quellcode<\/a> verfügbar. Systemd<\/a> ist nicht böse, weil es so viele undokumentierte Funktionen geben würde – sondern weil wohl nur der Red-Hat-Entwickler Poettering wirklich versteht, was Systemd<\/a> alles kann und wie es dies tut. Heute haben wir unter Linux<\/a> mit Systemd<\/a> ein einfach zu handhabendes Werkzeug für viele Dinge.<\/p>\n\n\n\n

Nach der Theorie noch ein wenig Technik<\/h3>\n\n\n\n

Hinter Systemd<\/a> stecken nicht nur die services<\/strong> – also die zu verwaltenden Dienste -, sondern auch die sockets<\/strong> – interne Netzwerk<\/a>verbindungen zwischen den Diensten – und die targets<\/strong>. Targets sind die Ziele, die mit Systemd<\/a> zu erreichen sind – also Zustände des Systems, die erreicht werden sollen.<\/p>\n\n\n\n

Unter dem vorangegangenen Link finden Sie weitere Informationen, hier sehen wir uns etwas mehr die Theorie an, um zu verstehen, wie die Technik dahinter funktioniert. Lassen wir uns beispielsweise einmal anzeigen, was hinter den Targets steckt. Es gibt etwa das Target reboot.target<\/strong> – es startet das Betriebssystem<\/a>, den Computer, neu. Um uns die einzelnen Services dahinter anzusehen, nutzen wir den Befehl<\/a> systemctl<\/code> mit der Option list-dependencies<\/code> und dem gewünschten Target:<\/p>\n\n\n\n

systemctl list-dependencies reboot.target<\/code><\/pre>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Um reboot.target<\/strong> auszuführen, sind also folgende Services auszuführen:<\/p>\n\n\n\n