WSL mit systemd

Das Windows Subsystem for Linux ist erwachsen geworden. Es ist nur für Windows 10 und Windows 11 im Microsoft Store erhältlich und gilt nicht mehr als »experimentell«. Der größte Vorteil der neuen Bezugsquelle: WSL-Updates werden in Zukunft unabhängig von Windows-Updates viel einfacher und schneller erfolgen.

Die Umstellung auf die Microsoft-Store-Variante ist denkbar einfach: Entweder installieren Sie WSL einfach aus dem Microsoft Store neu (vorhandene WSL-Distributionen bleiben dabei erhalten), oder Sie führen wsl --update aus (das setzt aber voraus, dass Ihre Windows-Version über alle aktuellen Updates verfügt).

Endlich systemd!

Aus meiner persönlichen Perspektive viel interessanter ist der Umstand, dass WSL nun endlich systemd unterstützt. Die Aktivierung erfolgt ganz einfach, in dem Sie in der WSL-Distribution die Datei /etc/wsl.conf verändern und dort zwei Zeilen hinzufügen:

# in /etc/wsl.conf  (innerhalb der WSL-Distribution)
[boot]
systemd=true

Die Änderung wird erst aktiv, wenn Sie die Distribution beenden, WSL herunterfahren (wsl --shutdown) und die Distribution dann neuerlich starten. Bei meinen Tests hat die systemd-Aktivierung erstaunlicherweise auch bei WSL-Distributionen funktioniert, die schon recht alt waren (z.B. Ubuntu 21.04).

Ubuntu 22.04 unter WSL 2 mit systemd und cron

Der entscheidende Fortschritt im Vergleich zu älteren WSL-Versionen ohne systemd besteht darin, dass es nun endlich unkompliziert möglich ist, Server-Dienste (SSH, Apache, MySQL usw.) so einzurichten, dass Sie mit dem Start der WSL-Distribution automatisch mitaktiviert werden. Auch Cron-Jobs funktionieren jetzt ohne Verrenkungen.

Beachten Sie, dass Server-Dienste nur zur Verfügung stehen, solange die betreffende WSL-Distribution aktiv ist, also ein WSL-Fenster geöffnet ist.

SSH-Ärger

Noch zwei Tipps zum Betrieb eines SSH-Servers unter WSL mit Ubuntu 22.04. Der initiale Start scheitert, weil es keine SSH-Host-Keys gibt, und weil die sonst übliche automatischer Erzeugung beim ersten Start aus mir nicht nachvollziehbaren scheitert. Abhilfe schafft einmalig ssh-keygen -A. Danach führt systemctl enable --now ssh zum Erfolg. Der Versuch, sich von Windows aus mit ssh <name>@172.30.xxx.yyy anzumelden, führt zum Fehler permission denied: publickey. Schuld ist die Einstellung PasswordAuthentication no in /etc/ssh/sshd_config innerhalb von Ubuntu. Stellen Sie die Option auf yes und starten Sie den SSH-Server neu, dann klappt es.

Alles in allem ist die Verwendung von SSH im Zusammenspiel mit WSL + Ubuntu 22.04 weiterhin mühsam.

WSL 1 und WSL 2

WSL liegt in zwei grundlegenden Varianten/Architekturen vor, die (noch) beide gepflegt werden.

  • WSL 2 greift auf einen »echten« Linux-Kernel zurück, der via Hyper-V in einer virtuellen Maschine ausgeführt wird. In den meisten Fällen ist diese Variante vorzuziehen. Sie ist schneller und funktioniert bei Hardware- oder Kernel-nahen Funktionen besser.

  • WSL 1 bildet dagegen Linux-Funktionen nach (und ist aus technischer Sicht viel bemerkenswerter). Die Integration der WSL-Distributionen in das lokale Netzwerk ist anders als bei WSL 2 (manchmal vorteilhafter). Der Hauptunterschied: WSL 1 erfordert keine Virtualisierung, läuft also auch dann, wenn sich Windows selbst in einer virtuellen Maschine befindet!

Standardmäßig wird bei einer WSL-Installation aus dem Microsoft Store nur WSL 2 aktiviert. Die für WSL 1 erforderlichen Features können aber problemlos mit wsl --install --enable-wsl1 nachinstalliert werden.

Losgelöst von der WLS-Architektur 1 und 2 gibt es auch eine WSL-Versionsnummer, die nichts mit der Architektur zu tun hat. wsl --version liefert aktuell 1.0.0.0 und zeigt, dass WSL dem Beta-Stadium entwachsen ist.

Nachwort

Aus meiner Linux-Perspektive ist es immer wieder erstaunlich, wie viele »offizielle« Wege es gibt, um Windows-Komponenten zu installieren:

  • Für WSL oder das neue Terminal verwenden Sie den Microsoft Store.

  • Andere Komponenten wie der SSH-Client und -Server sind tief in den Einstellungen versteckt (Apps / Optionale Features, das muss man wirklich erst mal finden …).

  • Wieder andere Komponenten wie Hyper-V & Co. gelten als Windows Features und werden über das gleichnamige Programm aktiviert.

Da soll noch einer sagen, Linux wäre schwer verständlich ;-)

Quellen/Links

6 Gedanken zu „WSL mit systemd“

  1. Danke für diesen informativen Artikel.
    Ich nutze hauptsächlich GNU-Linux auf meinen Maschinen, es gibt aber immer noch eine Win10 Installation auf meiner Workstation die ich hauptsächlich zum Gamen und Arbeiten für CAD usw. nutze.Oft muss ich hin und her booten evtl.
    hilft mir das WSL2 für bestimmte Aufgaben.
    Ich wusste gar nicht wie viel man inzwischen doch machen kann, wäre ja vor ein paar Jahren noch undenkbar gewesen.

    Vielen Dank für die Info.

  2. Die Datei /etc/wsl.conf existiert bei mir (standarmäßig?) nicht – der Blogbeitrag liest sich aber so, als wäre die Datei immer da. Wenn man sie mit dem im Blogbeitrag genannten Inhalt anlegt, WSL herunterfährt und neu startet, ist systemd aktiv.

  3. Leider wird viel zu häufig lapidar geschrieben WSL unterstütze nun systemd.
    Es gibt aber einige Merkwürdigkeiten. Die Sessions einer Distribution scheinen
    sich gegenseitig zu beeinflussen. Starte für eine dbus, pam, systemd user-session:
    wsl -u root -d fedoradistro — su user
    Dann gibts /run/user/1000/bus aber normal gestartet nur /run/user/1000/dbus-1
    Startet man nun zusätzlich normal ( loginctl list-sessions zeigt weitere Sitzung):
    wsl -u user -d fedoradistro
    gibts /run/user/1000/bus spontan nicht mehr ( in beiden Terminalfenstern).
    Das muß vielleicht so sein, hat mich aber kalt erwischt.
    MfG

Kommentare sind geschlossen.