Das Windows Subsystem für Linux (kurz WSL) bringt Linux zumindest ein Stück weit auf die Systeme von Nutzern, die keinen GNU/Linux Desktop einsetzen können, dürfen oder wollen. 6 Jahre nach dem Projektstart unterstützt WSL nun auch Systemd. Doch in der Praxis erscheint trotzdem oft ein Fehler: System has not been booted with systemd as init system (PID 1): can’t operate. Dieser Beitrag zeigt Ursachen und Lösungen für Windows 11 sowie erklärt dir, warum Systemd unter GNU/Linux wichtig ist. Auch auf Alternativen geht er ein, denn es gibt mehrere Möglichkeiten, mit diesem WSL-Fehler umzugehen.
Was ist Systemd und warum brauche ich es?
Systemd ist ein Initialisierungssystem, der nach dem Booten aufgerufen wird und wichtige Bestandteile einer GNU/Linux-Distribution startet: Beispielsweise das Einhängen der Laufwerke, aber auch das Starten von Hintergrundprogrammen und Diensten, wie etwa Serversoftware. Im Grunde kümmert sich Systemd um die gesamte Verwaltung aller laufenden Dienste, auch über den Start hinaus.
WSL hat damit vor allem dann Probleme, wenn Dienste bzw. Daemons im Hintergrund gestartet werden: Ein Webserver oder eine Datenbank legt beispielsweise automatisch eine Systemd-Unit an, worüber sie die Software starten. Docker und Snap benötigen Daemons also Hintergrunddiensten, mit denen die Kommandozeilenwerkzeuge kommunizieren. Wenn Systemd von WSL nicht gestartet wird, funktioniert all das nicht. Man kann sich teilweise über Workarounds behelfen, und etwa einen Webserver im Vordergrund auf der Konsole starten. Das ist – zumindest unter WSL – je nach Anwendungszweck entweder akzeptabel oder umständlicher.
Gibt es Alternativen zu Systemd?
Jein: Init.d-Skripte sind sozusagen der Vorgänger – und obwohl diese in vielen Distributionen durch Systemd abgelöst wurden, bringen einige Pakete sie nach wie vor mit. Man findet sie (falls vorhanden) im Ordner /etc/init.d und kann Dienste nach folgendem Syntax starten: service <name> start|stop|restart|status
Eine weitere Möglichkeit besteht darin, die Anwendung hinter z.B. benötigten Daemons selbst zu starten. Die Unit-Datei des Systemd-Dienstes kann helfen, die korrekte Binary zu finden. Je nach konkreter Software hat man mit diesen Wegen mehr oder weniger Extra-Aufwand, bis dies funktioniert, sowie im Einzelfall ggf. auch Nachteile. Die einfachste und komfortabelste Methode besteht daher darin, Systemd nachzurüsten – so kommt man einer nativen GNU/Linux-Distribution deutlich näher, auf der die Software ja auch vorhanden ist, sodass keine händischen Bastelleien notwendig sind.
Wer es dennoch ohne Systemd versuchen möchte, wird sich darüber ärgern, sämtliche Hintergrund-Dienste bei jedem WSL- bzw. PC-Start von Hand neu Starten zu müssen. Beispielsweise service docker start, wenn Docker in der WSL-Instanz läuft. Dafür bietet WSL einen Kompromiss: Es kann einen Befehl vor dem Start einer Instanz ausführen. Dafür fügt man folgenden Block in die /etc/wsl.conf Datei ein:
[boot]
command = service docker startVoraussetzungen: Das müsst ihr beachten, um Systemd unter WSL nutzen zu können
Nachdem ab 2011 mehr und mehr große Distributionen zu Systemd gewechselt sind, zieht Microsoft sehr spät nach: offziell in WSL ab 0.67.6 im Jahre 2022 und funktioniert zudem nur unter bestimmten Umständen sowie mit Anpassungen. Nur über die per Store/manuell installierte Version kann Systemd genutzt werden. Ursprünglich kamen WSL 1 und 2 als Windows-Funktion, waren also in Windows eingebettet. Dieser weg wurde auch von Microsoft dokumentiert.
Ende 2022 wurde WSL mit Anwendungsversion 1.0 zusätzlich als Windows-Anwendung verfügbar gemacht: Es kann fortan per Microsoft Store oder als ausführbare Datei installiert werden kann. Erst mit Windows 11 ab 22H2 hat Microsoft das Chaos ab Werk gelichtet und liefert die neueste Store/Binary-Version aus. Ältere Installationen die den offiziellen Weg über die Windows-Features nutzen, werden laut meinen Tests per Windows Update nachgerüstet. Hier sieht man dies anhand einer Vanilla Windows 10 21H2 Installation, auf der alle Aktualisierungen eingespielt wurden:
Das laut Microsoft unter Windows 10 erforderliche Update KB5020030 war dafür nicht nötig, es wurde in meiner Vanilla Testinstallation gar nicht angeboten. Bei Windows 10 22H2 genügt ebenfalls das Installieren aller von MS als verpflichtend erachtenden Updates, also ohne die Optionalen. Es muss also eines von den drei Updates aus der Liste unten sein:
Wer den richtigen Installationsweg verwendet hat und eine ältere Version besitzt, kann per wsl –update übrigens aktualisieren. Über wsl –version kann man laut Microsoft beide Versionen unterscheiden: Erzeugt der Befehl einen Fehler statt die Version zu zeigen, nutzt man die integrierte per Windows Features installierte Version, die Systemd nicht unterstützt.
In meinem Falle war das auf einer frischen Installation mit keiner unterstützten Windows 10 Version (21H2/22H2) reproduzierbar, nachdem alle Updates eingespielt wurden. Sollte es unter Umständen dennoch Probleme geben, muss man das „neue“ WSL über den Windows Store oder die Binaries auf GitHub nachinstallieren – obwohl WSL über die Windows-Features bereits vorinstalliert ist. Der Windows Store ist mittlerweile ohne Kontozwang nutzbar.
Unter Windows 10 versucht der Store zwar noch, einen zur Anmeldung zu motivieren. Dies kann jedoch zumindest zum Erstellzeitpunkt des Artikels noch mit einem Klick auf Nein, danke umgangen werden. Dass Microsoft die Daumenschrauben durchaus enger legen kann, zeigt der MS-Kontozwang in Windows 11: Dieser wurde zunächst für die Home-Edition eingeführt und mit dem 22H2 Update auch auf Pro ausgedehnt. Alternativ kann man sich die MSIBUNDLE-Installationsdatei auch von den GitHub-Releases herunterladen und händisch installieren.
Spätestens nach der manuellen Installation sollte eine Versionsausgabe erfolgen, womit ihr bereit für Systemd seid.
Systemd funktioniert trotz Unterstützung nicht?
Selbst wenn man die richtige und aktuellste Version hat, funktioniert Systemd immer noch nicht: Ein sudo systemctl status liefert den Fehler System has not been booted with systemd as init system (PID 1): can’t operate. Failed to connect to bus: Host is down.
Man muss es unter Windows nämlich zuerst von Hand mit einem etwas versteckten Weg aktivieren. Dazu startet man mit wsl eine WSL-Instanz und legt die Datei /etc/wsl.conf an, die standardmäßig ebenfalls nicht existiert – etwa mit sudo nano /etc/wsl.conf, wenn man mit vim nicht vertraut ist. Dort folgende zwei Zeilen einfügen:
[boot]
systemd=trueNach dem Speichern die WSL-Instanz mit Exit verlassen und komplett beenden:
wsl --shutdownMeist reicht das, vereinzelt kommt es jedoch zu Problemen, da Windows wohl noch etwas im Zugriff hat – reproduzieren konnte ich dies nicht, weswegen ich an dieser Stelle einen kompletten Neustart des PCs empfehlen würde. Nur so lässt sich sichergehen, dass WSL komplett beendet wurde.
Nun sollte WSL endlich auch Systemd starten, womit viele GNU/Linux Software überhaupt erst richtig bzw. ohne händische Anpassungen funktioniert. Beispielhaft habe ich Apache2 installiert: Die Installation erzeugt keine Fehler mehr und der Webserver läuft ohne Anpassungen über seinen gleichnamigen, standardmäßig angelegten Systemd-Dienst:
sudo apt install -y apache2
Die erstmalige Startzeit erhöht sich durch Systemd auf einer leeren Instanz von 2,5 auf 4,9 Sekunden. Gemessen wurde mit Ubuntu 22.04 und folgendem Befehl:
wsl --shutdown
Measure-Command { wsl whoami }