Smf

In diese Lücke stieß Lennart Pöttering. Und er stieß nicht nur hinein, er sprengte das ganze Haus.

Er sah sich nicht das robusteste, erwachsenste Service-Management-System der Welt an – Solaris SMF (2005), das auf Stabilität, Verträge und Selbstheilung ausgelegt war.

Nein, er schaute auf macOS und dessen launchd (ebenfalls 2005). launchd war elegant, XML-basiert und vor allem: Es liebte Socket-Aktivierung. Die Idee, dass Dienste nicht laufen, bis sie wirklich gebraucht werden. Eine coole Idee für einen Laptop, auf dem Akku gespart werden soll.

Pöttering nahm diese Idee und machte daraus eine Religion.

Der Sündenfall: Von PID 1 zur Alles-Maschine

systemd hat nicht nur das Init-Problem gelöst. Es hat beschlossen, dass alles ein Init-Problem ist.

Wo SMF (Solaris) ein sauberer, fokussierter Service Manager war, der neben dem Kernel lebte, wurde systemd zum alles verschlingenden Monolithen in PID 1.

systemd ist nicht nur ein Init-System. Es ist:

• journald (Dein Logger, ob du willst oder nicht)
• networkd (Dein Netzwerk-Manager)
• resolved (Dein DNS-Client, der sich mit 127.0.0.53 an glibc vorbeimogelt)
• logind (Dein Session-Manager)
• timesyncd (Dein NTP-Client)
• …und gefühlt 50 andere Tools, die früher separate, austauschbare Binaries waren.

Pöttering hat sich dabei nicht beliebt gemacht, weil er nicht nur Code schrieb, sondern die gesamte UNIX-Philosophie (“Mache eine Sache und mache sie gut”) aktiv angriff. Er ersetzte kleine, scharfe Werkzeuge durch ein zentralisiertes, binäres System, das man “gefälligst als Ganzes” zu nehmen hat.

Die “Lösung”, die das Problem verschob

Ja, systemd bootet schnell. Ja, Abhängigkeiten funktionieren (meistens). Aber zu welchem Preis?

• Komplexität: SMF war lesbares XML. systemd-Units sind zwar einfacher, aber das Debugging des Systems (warum resolved spinnt, warum journald Logs frisst) ist ein Albtraum.
• Der Monolith: Wenn systemd ein Problem hat, hat dein ganzer Server ein Problem. Es gibt keinen “Plan B”, wenn PID 1 hustet.
• Der “Lock-in”: Pöttering hat systemd so tief ins System (insbesondere in den GNOME-Desktop und tiefe glibc-Funktionen) verwoben, dass es heute fast unmöglich ist, ein modernes Linux ohne systemd zu betreiben. Das ist kein technischer Fortschritt, das ist eine feindliche Übernahme.

Fazit

Wir haben das init.d-Chaos nicht durch eine saubere, fokussierte Lösung (wie SMF sie war) ersetzt. Wir haben es durch einen Laptop-inspirierten (launchd) Overkill ersetzt, der das gesamte Betriebssystem in PID 1 gesaugt hat.

Quellen und Links

• systemd for Linux SysAdmins: von David Both
• CRE-Podcast: Interview mit Lennart