Exécuter systemd dans WSL : ce qui fonctionne maintenant (et ce qui casse encore)

février 19, 2026 • février 19, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous vouliez un environnement Linux sur Windows qui se comporte comme vos serveurs réels. Puis vous avez tapé
systemctl status dans WSL et obtenu la réplique classique : « System has not been booted with systemd. »
Soudain votre « machine dev rapide » se transforme en boîte de Pétri bizarroïde de démons à moitié fonctionnels, logs
absents et services qui ne démarrent que si vous pensez à les lancer.

La bonne nouvelle : systemd dans WSL est désormais un mode réellement supporté, pas un empilement de bidouilles.
La mauvaise nouvelle : ce n’est toujours pas une VM complète, ce n’est pas votre noyau de production, et certaines
choses plantent d’une manière qui semble personnelle.
Voici la carte pratique — ce qui marche, ce qui casse, et comment déboguer comme si vous étiez d’astreinte.

La situation actuelle : systemd dans WSL aujourd’hui

Si vous êtes sur WSL2 et que votre package WSL est relativement à jour, vous pouvez activer systemd par distribution en utilisant
/etc/wsl.conf. WSL lancera alors systemd comme PID 1 à l’intérieur de la distro, et le reste de vos services
se comportera comme sur une machine Linux normale — majoritairement.

Le « majoritairement » compte ici. WSL n’est pas un hyperviseur générique. C’est un noyau Linux hébergé par Windows avec une couche
d’intégration étroite. Certains éléments de plomberie sont différents par conception : le réseau est virtualisé ; les montages
sont traduits ; le cycle de vie est piloté par la session ; Windows garde toujours la main sur la gestion d’alimentation et le réseau hôte.

Mes conseils opinionnés :

Utilisez systemd dans WSL quand vous avez besoin d’une gestion de services réaliste (Docker Engine, podman, sshd,
timers, journald, services médiés par dbus).
N’utilisez pas WSL comme production (oui, des gens essaient). Traitez-le comme un environnement dev/CI au comportement proche de la prod, pas comme un substrat de production.
Gardez une frontière entre « services Linux » et « responsabilités de l’hôte Windows ». Quand vous brouillez cette frontière, le dépannage devient de l’art performance.

Comment systemd démarre réellement dans WSL (et pourquoi c’est important)

Historiquement, WSL lançait votre shell (ou la commande configurée) directement ; il n’y avait pas de système init. Cela signifiait :
pas de PID 1 supervisant les services, pas de cible de boot cohérente, et pas de logs gérés par journald. Si un démon mourait,
il mourait en silence ou laissait un fichier PID obsolète comme petite stèle.

Avec systemd activé, WSL démarre systemd comme PID 1. D-Bus est embarqué et les unités systemd peuvent tourner normalement.
Vous disposez maintenant d’une façon cohérente de démarrer des services, définir des dépendances, définir des politiques de restart,
et utiliser des timers au lieu de « je l’ai mis dans mon fichier rc de shell en espérant que ça marche ».

Mais le « boot » de WSL n’est pas un boot matériel. C’est un démarrage en espace utilisateur dans un environnement géré. Deux conséquences
apparaissent immédiatement :

Le cycle de vie est lié à l’instance WSL. Quand WSL s’arrête (ou est terminé), vos services s’arrêtent.
Lorsqu’il démarre, l’ordre des unités se produit, mais ce n’est pas identique à un démarrage de serveur complet avec découverte de périphériques.
Les couches d’intégration peuvent remplacer des valeurs Linux par défaut. La résolution DNS, les interfaces réseau et les montages
peuvent se comporter différemment que lors d’une installation de distribution classique.

La leçon pratique : considérez systemd dans WSL comme « une vraie gestion de services Linux tournant dans un conteneur hôte contraint »,
pas comme « j’ai installé Ubuntu ». Ce cadrage évite beaucoup de mauvaises hypothèses.

Faits intéressants et contexte historique

Voici des points courts et concrets qui expliquent pourquoi ce sujet reste épicé :

WSL1 n’utilisait pas du tout un noyau Linux ; il traduisait les appels système Linux en appels du noyau Windows NT.
Ce modèle était ingénieux, mais limitait la compatibilité pour les charges dépendantes du noyau.
WSL2 est passé à un vrai noyau Linux tournant dans une VM légère. C’est pourquoi les conteneurs et les cgroups sont devenus viables.
Pendant des années, systemd n’était pas supporté dans WSL, en partie parce que WSL ne se présentait pas comme un système amorcé traditionnel
avec la propriété de PID 1 et la gestion des périphériques.
Les premières tentatives d’« systemd sur WSL » reposaient sur des scripts wrapper et des astuces pour PID 1. Elles fonctionnaient
jusqu’à ce qu’elles ne fonctionnent plus, et elles plantaient de façons délicieusement confuses.
Les distributions Linux comptent de plus en plus sur systemd. Même quand un service peut tourner sans, le packaging et l’intégration supposent souvent
l’existence d’unités systemd.
systemd n’est pas juste « un init » ; c’est une suite (journald, resolved, networkd, logind, timers, dépendances d’unités). Dans WSL, vous pouvez vouloir
exactement certains de ces composants et pas d’autres.
cgroup v2 est le défaut moderne dans de nombreux environnements. Cela compte pour Docker, podman et tout contrôle de ressources ; WSL2 a amélioré le support des cgroups.
Le réseau WSL utilisait historiquement du NAT avec une IP VM changeante. Cela convient pour les appels sortants et complique les services entrants à moins de s’en prémunir.
WSL régénère des parties de votre config Linux (notamment /etc/resolv.conf) à moins que vous ne lui indiquiez le contraire, ce qui entre en collision
avec les attentes de systemd-resolved.

Ce qui fonctionne bien (assez) avec systemd dans WSL

Gestion des services qui ressemble à Linux

Le bénéfice principal est évident : systemctl fonctionne. Les unités peuvent démarrer au « boot » (démarrage d’instance WSL),
redémarrer en cas d’échec et exprimer des dépendances. Cela veut dire :

sshd peut être un service, pas une commande manuelle que vous oubliez.
les tâches de type cron peuvent être des timers systemd avec logs et gestion d’échecs.
les services qui utilisent dbus se comportent comme sur les serveurs.

journald rend le débogage moins superstitieux

Sans journald, vous finissez par parcourir des fichiers aléatoires sous /var/log et vous demander pourquoi rien n’y est.
Avec systemd, vous pouvez interroger des logs structurés par unité, par démarrage et par plage temporelle. Ce n’est pas magique, mais c’est
prévisible — ma saveur préférée de la magie.

Docker Engine et compagnons peuvent être plus « natifs Linux »

Beaucoup d’équipes utilisent Docker Desktop avec intégration WSL, ce qui peut marcher sans systemd. Mais si vous voulez exécuter
Docker Engine à l’intérieur de la distro comme sur un hôte Linux, le support systemd enlève beaucoup de petites frictions :
fichiers d’unité, patterns d’activation par socket et démarrage prévisible.

Les timers systemd sont une alternative saine au « backgrounding »

Les sessions WSL vont et viennent. Les processus en arrière-plan que vous avez lancés manuellement peuvent disparaître, ou rester actifs et
vous surprendre plus tard. Timers + services vous donnent une planification idempotente et inspectable.

Ce qui casse encore ou reste étrange

DNS et resolv.conf : le piège intemporel

WSL aime gérer le DNS pour vous. systemd-resolved aime gérer le DNS pour vous. Mettez-les ensemble et vous pouvez obtenir :
résolution de noms manquante, comportement différent entre l’hôte et WSL, ou « ça marchait jusqu’à ce que je me reconnecte au Wi‑Fi ».

La correction n’est généralement pas compliquée, mais elle exige de choisir qui possède la configuration. Soit laissez WSL générer
/etc/resolv.conf et n’exécutez pas systemd-resolved, soit désactivez la génération WSL et configurez correctement resolv.conf pour resolved.
L’indécision est le pire outil de gestion de configuration.

Le réseau pour les services entrants n’est toujours pas « comme en serveur »

Le réseau entrant dépend de la façon dont Windows expose les ports à la VM WSL. Votre service peut écouter sur
127.0.0.1 dans WSL et être injoignable depuis Windows, ou l’inverse. Parfois l’adresse de bind « correcte »
est contre-intuitive. Parfois elle change avec les mises à jour.

Sémantique des montages : /mnt/c est pratique et lent

Le système de fichiers Windows monté sous /mnt/c est excellent pour l’interopérabilité et terrible pour les charges
qui veulent la sémantique et la vitesse d’un FS Linux (builds lourds en métadonnées, bases de données, gros dépôts Git).
systemd ne règle pas ça ; il organise juste la douleur de façon plus nette.

Tous les réglages noyau ne se comportent pas comme dans votre datacenter

Le noyau de WSL est réel, mais il est géré. Certains modules, sysctls et comportements de périphériques peuvent différer de votre flotte.
Si vous testez quelque chose de sensible au noyau, validez aussi sur une vraie VM Linux.

Blague #1 : WSL avec systemd, c’est comme donner un pager à votre laptop de dev — soudain il a des opinions sur l’uptime.

Tâches pratiques : commandes, sorties et décisions

La façon la plus rapide de savoir si votre configuration est « suffisamment saine » est de l’interroger comme vous le feriez sur un hôte de production.
Ci‑dessous des commandes réelles, à quoi ressemble une sortie réaliste, et la décision à prendre.

Task 1: Confirm you’re on WSL2 (not WSL1)

cr0x@server:~$ uname -r
5.15.133.1-microsoft-standard-WSL2

Ce que ça signifie : Si la chaîne du noyau inclut microsoft-standard-WSL2, vous êtes sur WSL2.

Décision : Si vous êtes sur WSL1, arrêtez. systemd est supporté pour WSL2. Convertissez la distro en WSL2 avant de continuer.

Task 2: Verify PID 1 is systemd

cr0x@server:~$ ps -p 1 -o pid,comm,args
  PID COMMAND         COMMAND
    1 systemd         /sbin/init

Ce que ça signifie : PID 1 étant systemd est l’essentiel.

Décision : Si PID 1 est init ou bash, systemd n’est pas activé (ou WSL n’a pas redémarré proprement).

Task 3: Check WSL systemd enablement configuration

cr0x@server:~$ cat /etc/wsl.conf
[boot]
systemd=true

Ce que ça signifie : C’est l’interrupteur par distro.

Décision : Si manquant/false, mettez-le, puis redémarrez l’instance WSL depuis Windows (ou terminez cette distro) pour que ça prenne effet.

Task 4: Prove systemd is functional (not just present)

cr0x@server:~$ systemctl is-system-running
running

Ce que ça signifie : running est sain. Vous pourriez aussi voir degraded si une unité a échoué.

Décision : Si degraded, listez immédiatement les unités en échec et corrigez la première défaillance qui compte.

Task 5: List failed units and pick the right fight

cr0x@server:~$ systemctl --failed
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● systemd-resolved.service loaded failed failed Network Name Resolution
● snapd.service            loaded failed failed Snap Daemon

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state, often a more detailed state.
2 loaded units listed.

Ce que ça signifie : Quelques valeurs par défaut échouent dans WSL, selon la distro et la configuration.

Décision : Si l’unité en échec est non pertinente (comme snapd dans beaucoup d’installations dev WSL), masquez-la. Si c’est resolved, corrigez d’abord la propriété du DNS.

Task 6: Inspect why a unit failed (systemd’s perspective)

cr0x@server:~$ systemctl status systemd-resolved.service --no-pager -l
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2026-02-05 09:12:17 UTC; 25s ago
       Docs: man:systemd-resolved.service(8)
    Process: 412 ExecStart=/lib/systemd/systemd-resolved (code=exited, status=1/FAILURE)
     Status: "Failed to read /etc/resolv.conf: Too many levels of symbolic links"

Ce que ça signifie : Une boucle classique : resolved veut un lien symbolique vers le stub resolv.conf, WSL peut le réécrire, et vous obtenez un cirque de symlinks.

Décision : Décidez qui possède /etc/resolv.conf. Puis implémentez proprement et redémarrez l’unité.

Task 7: Check who owns DNS right now

cr0x@server:~$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 116 Feb  5 09:10 /etc/resolv.conf

Ce que ça signifie : Un fichier régulier suggère typiquement que WSL l’a généré (ou que vous l’avez figé manuellement).

Décision : Si vous voulez systemd-resolved, en général vous voulez que /etc/resolv.conf soit un symlink vers le stub de resolved ou un fichier généré — sans réécriture par WSL.

Task 8: Confirm journald is capturing logs (and not silently useless)

cr0x@server:~$ journalctl -b -n 10 --no-pager
Feb 05 09:12:01 server systemd[1]: Starting Network Name Resolution...
Feb 05 09:12:17 server systemd[1]: systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 09:12:17 server systemd[1]: systemd-resolved.service: Failed with result 'exit-code'.
Feb 05 09:12:17 server systemd[1]: Failed to start Network Name Resolution.
Feb 05 09:12:20 server systemd[1]: Starting OpenSSH Daemon...
Feb 05 09:12:20 server sshd[522]: Server listening on 0.0.0.0 port 22.
Feb 05 09:12:20 server systemd[1]: Started OpenSSH Daemon.

Ce que ça signifie : Vous avez des logs liés au boot. C’est votre source de vérité désormais.

Décision : Si journald est vide ou génère des erreurs, corrigez le logging avant de chasser des bugs de services. Pas de logs = débogage à l’intuition.

Task 9: Check dbus health (lots of things quietly depend on it)

cr0x@server:~$ systemctl status dbus --no-pager
● dbus.service - D-Bus System Message Bus
     Loaded: loaded (/lib/systemd/system/dbus.service; static)
     Active: active (running) since Mon 2026-02-05 09:12:00 UTC; 1min 2s ago
TriggeredBy: ● dbus.socket
       Docs: man:dbus-daemon(1)
   Main PID: 210 (dbus-daemon)
      Tasks: 1 (limit: 18947)
     Memory: 2.3M
     CGroup: /system.slice/dbus.service
             └─210 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

Ce que ça signifie : dbus tourne, l’activation par socket fonctionne.

Décision : Si dbus est mort, attendez-vous à des comportements « étranges » partout : hostnamectl, timedatectl, resolved, outils adjacents à logind.

Task 10: Verify cgroup version (containers care)

cr0x@server:~$ stat -fc %T /sys/fs/cgroup
cgroup2fs

Ce que ça signifie : cgroup2fs indique cgroup v2. Les anciennes configurations peuvent afficher tmpfs et exiger une config différente pour les conteneurs.

Décision : Si vous exécutez Docker Engine ou podman, alignez vos attentes sur le driver de cgroup disponible.

Task 11: If Docker is installed, check the daemon unit

cr0x@server:~$ systemctl status docker --no-pager
● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-02-05 09:12:45 UTC; 35s ago
TriggeredBy: ● docker.socket
       Docs: man:dockerd(8)
   Main PID: 900 (dockerd)
      Tasks: 18
     Memory: 78.4M
     CGroup: /system.slice/docker.service
             └─900 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Ce que ça signifie : Démon en cours d’exécution, activation par socket, chemin cgroup normal en apparence.

Décision : Si Docker échoue, vérifiez les cgroups, les hypothèses iptables/nft et si vous entrez en conflit avec l’intégration Docker Desktop.

Task 12: Check what’s listening and where (127.0.0.1 vs 0.0.0.0)

cr0x@server:~$ ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=522,fd=3))
LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=1203,fd=6))

Ce que ça signifie : sshd est joignable sur toutes les interfaces à l’intérieur de WSL ; postgres est lié à loopback seulement.

Décision : Si Windows ne peut pas atteindre un service, regardez d’abord les adresses de bind. « Ça tourne » n’est pas « c’est joignable ».

Task 13: Confirm mount type for your project directory

cr0x@server:~$ df -T .
Filesystem     Type  1K-blocks      Used Available Use% Mounted on
/dev/sdd       ext4  263174212  18234568 231513928   8% /

Ce que ça signifie : Si vous êtes sur ext4 dans le système de fichiers Linux, la performance est généralement correcte.

Décision : Si votre projet vit sous /mnt/c (typiquement 9p ou similaire), déplacez-le dans le filesystem de la distro pour les builds lourds/bases de données.

Task 14: Identify if WSL is rewriting resolv.conf behind your back

cr0x@server:~$ grep -n "generateResolvConf" /etc/wsl.conf || true

Ce que ça signifie : Pas de sortie signifie généralement comportement par défaut (WSL peut générer resolv.conf).

Décision : Si vous voulez un DNS déterministe avec systemd-resolved, définissez explicitement generateResolvConf=false et gérez le fichier/symlink vous‑même.

Task 15: Check boot performance and blame the slow units

cr0x@server:~$ systemd-analyze blame | head
3.214s snapd.service
1.122s docker.service
 812ms systemd-resolved.service
 402ms ssh.service
 211ms systemd-journald.service

Ce que ça signifie : Vous avez des timings par unité. C’est de l’or quand « WSL rame aujourd’hui ».

Décision : Masquez ou désactivez les unités non pertinentes dans WSL qui ralentissent chaque démarrage.

Task 16: Prove a timer works and produces logs

cr0x@server:~$ systemctl list-timers --all --no-pager | head
NEXT                        LEFT     LAST                        PASSED  UNIT                         ACTIVATES
Mon 2026-02-05 09:20:00 UTC 2min 10s Mon 2026-02-05 09:15:00 UTC 2min ago apt-daily.timer              apt-daily.service
Mon 2026-02-05 10:00:00 UTC 42min    Mon 2026-02-05 09:00:00 UTC 17min ago man-db.timer                man-db.service

Ce que ça signifie : Les timers sont planifiés et suivis.

Décision : Si vous dépendez de tâches planifiées, préférez les timers aux hacks shell. Si les timers spamment les logs ou consomment du CPU, ajustez ou désactivez-les.

Feuille de route de diagnostic rapide

Quand systemd-dans-WSL est « cassé », il échoue rarement d’une manière nouvelle. La plupart des incidents reviennent aux mêmes petits modes de défaillance
portant différents masques. Voici l’ordre qui vous amène rapidement au goulot d’étranglement.

Première étape : systemd est-il réellement PID 1 et le système est-il opérationnel ?

ps -p 1 -o comm,args → si ce n’est pas systemd, arrêtez et corrigez l’activation / redémarrez WSL.
systemctl is-system-running → si degraded, listez les unités en échec et traitez la première pertinente.

Deuxième étape : les logs sont-ils utilisables ?

journalctl -b -n 50 → si vide, vous n’avez pas d’observabilité ; corrigez journald/permissions de stockage ou vos attentes.
journalctl -u <service> -b → si le service échoue, préférez ceci aux fichiers logs aléatoires.

Troisième étape : est‑ce DNS/réseau ou le service lui‑même ?

resolvectl status (si vous utilisez resolved) ou inspectez /etc/resolv.conf.
ss -lntp pour confirmer adresses de bind et listeners.
ip addr + ip route pour confirmer que les interfaces et la route par défaut existent.

Quatrième étape : des montages ou une unité lente tuent-ils les performances ?

df -T et sanity check du chemin : ne gérez pas de bases sur /mnt/c si vous voulez du bonheur.
systemd-analyze blame pour identifier les unités lentes au démarrage ; désactivez ce dont vous n’avez pas besoin.

Cinquième étape : workloads conteneurisés — confirmez les cgroups et hypothèses du démon

stat -fc %T /sys/fs/cgroup pour confirmer cgroup v2.
systemctl status docker et journalctl -u docker -b pour les erreurs du démon.

L’objectif n’est pas de « tester des corrections au hasard ». L’objectif est de classifier le problème en moins de cinq minutes.

Trois mini-histoires d’entreprise (toutes réelles, aucune traçable)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe proche de la finance a standardisé WSL pour le développement parce que cela réduisait la variance des laptops. Ils ont ajouté systemd
pour que les services démarrent « comme en prod ». Ça a marché pendant des mois. Puis un nouveau développeur a rejoint, a pullé le repo, lancé le bootstrap,
et son maillage de services local n’a jamais démarré correctement.

L’hypothèse erronée était subtile : ils supposaient que le « boot » WSL équivalait au boot d’une VM et que les unités systemd seraient
démarrées avant l’arrivée du premier prompt du développeur de façon fiable. En pratique, le démarrage d’instance WSL est déclenché par
le lancement de la distro, et le timing dépend de ce que fait l’hôte. Le script de bootstrap a immédiatement exécuté une commande cliente contre
un service encore en démarrage, a échoué une fois, puis a mis en cache l’état d’échec dans une config locale.

Le symptôme ressemblait à un problème réseau : timeouts, connexions refusées, et une personne affirmant « ça marche sur ma machine », ce qui est
à la fois une affirmation et un mode de vie. La cause racine était simplement l’ordre : les services étaient corrects mais pas prêts quand on les interrogeait,
et le script n’avait ni retries ni backoff.

La correction fut ennuyeuse : ajouter des checks de readiness (systemd After= et Wants= quand approprié, plus une boucle cliente de retry
avec timeouts), et cesser de traiter le comportement de premier démarrage comme déterministe. Ils ont aussi ajouté une unique commande « health » qui vérifie les unités critiques et produit une sortie actionnable.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre équipe poursuivait des builds plus rapides. Ils ont remarqué que garder le code sous /mnt/c facilitait l’édition depuis Windows,
mais rendait les builds lents. Quelqu’un a proposé une « optimisation » : symlinker les outputs et caches de build vers le stockage Windows pour qu’ils survivent
aux resets WSL et soient partagés entre distros.

Ça a accéléré quelques builds petits et puis a explosé comme seules les optimisations I/O peuvent le faire : les plus grands builds ont commencé à échouer
de façon intermittente. Ils ont vu des caches d’artifacts corrompus, des erreurs de permissions sporadiques et des tempêtes de watchers de fichiers.
systemd n’était pas la cause directe, mais il a rendu le problème plus visible parce que des services en arrière-plan tournaient désormais de façon fiable —
indexeurs, language servers et file watchers étaient actifs et amplifiaient les pires traits du système de fichiers.

Le retour de manivelle était classique : le FS monté Windows avait des sémantiques et des performances différentes. Les opérations sur les métadonnées
étaient plus lentes, les verrous de fichiers se comportaient autrement, et toute la chaîne devenait sensible au timing. L’équipe a passé une semaine à « tuner »
avant d’admettre que le plan était défaillant.

La correction fut de garder les caches lourds et les dépôts dans le système de fichiers Linux (ext4 dans le disque virtuel WSL), puis d’exposer seulement
les artefacts finaux vers Windows si nécessaire. Ils ont conservé une étape explicite de « sync » plutôt que d’essayer de faire partager un répertoire chaud entre les deux mondes.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un groupe plateforme maintenait un environnement dev basé sur WSL pour des dizaines d’ingénieurs. La configuration incluait systemd, Docker, un miroir de registry local
et quelques agents internes. C’était le type d’environnement qui marche jusqu’à un mardi matin où tout le monde met à jour quelque chose et que le chaos éclate.

Leur pratique ennuyeuse : ils gardaient un script de diagnostic « golden » minimal et versionné qui exécutait les mêmes vérifications à chaque fois : PID 1, unités en échec,
derniers logs de boot, propriété DNS, sockets en écoute, type de disque pour le répertoire de travail, et santé du démon conteneur. Il imprimait des lignes simples ok/ko
et suggérait la commande suivante.

Quand une mise à jour WSL a changé suffisamment le comportement réseau pour casser les connexions entrantes sur une sous-partie des laptops, le groupe n’a pas passé des heures
à débattre sur la malédiction de la machine de quelqu’un. Ils ont lancé le script, ont vu que les services écoutaient sur 127.0.0.1, et que Windows ne pouvait plus les atteindre.
Le pattern était reproductible.

Parce qu’ils avaient une baseline et des logs, ils ont pu écrire une correction ciblée : ajuster les adresses de bind pour les services dev, mettre à jour des règles firewall
sur l’hôte, et documenter un workaround unique pour les utilisateurs affectés en attendant un correctif Windows plus permanent. Ce n’était pas glamour, mais cela a évité une panne de productivité lente.

Erreurs courantes : symptôme → cause racine → correction

1) « System has not been booted with systemd »

Symptôme : systemctl renvoie des erreurs, les unités ne peuvent pas être gérées.

Cause racine : systemd non activé, ou instance WSL non redémarrée après changement de config.

Correction : Mettre [boot] systemd=true dans /etc/wsl.conf et redémarrer l’instance WSL. Confirmer que PID 1 est systemd.

2) DNS fonctionne une fois puis casse après des changements réseau

Symptôme : apt update échoue, noms internes ne se résolvent plus après changement VPN/Wi‑Fi.

Cause racine : Conflit de propriété : WSL régénère /etc/resolv.conf tandis que systemd-resolved s’attend à contrôler ce fichier (ou l’inverse).

Correction : Choisir un propriétaire. Si vous utilisez resolved, définissez generateResolvConf=false et pointez /etc/resolv.conf vers le fichier attendu par resolved sans créer de boucle. Si vous n’utilisez pas resolved, désactivez/masquez-le.

3) Les services tournent mais sont injoignables depuis Windows

Symptôme : curl localhost:PORT fonctionne dans WSL mais pas depuis Windows, ou inversement.

Cause racine : Mauvaise adresse de bind (127.0.0.1 vs 0.0.0.0), hypothèses NAT/port forwarding, ou firewall hôte.

Correction : Utilisez ss -lntp pour voir où c’est lié. Liezt vos services délibérément. Si besoin, ajustez les règles Windows firewall.

4) WSL semble lent « après activation de systemd »

Symptôme : Le démarrage de la distro paraît plus lourd ; les commandes laggent ; pics CPU au lancement.

Cause racine : Services inutiles qui démarrent automatiquement (snapd, timers apt, indexeurs), ou choix de système de fichiers (travail sous /mnt/c).

Correction : Utilisez systemd-analyze blame et systemctl --failed. Désactivez/masquez les unités non nécessaires. Déplacez les gros projets dans le filesystem Linux.

5) Docker dans WSL échoue bizarrement (iptables, cgroups, permissions)

Symptôme : Le démon Docker ne démarre pas, les conteneurs ne peuvent pas créer de réseaux, erreurs sur cgroups ou nft.

Cause racine : Attentes non alignées : cgroup v2 vs v1, différences de backend firewall, ou conflit avec l’intégration Docker Desktop.

Correction : Confirmez le mode cgroup, inspectez journalctl -u docker -b, et choisissez un modèle : Docker Desktop-managed ou Docker géré dans la distro. Mixer augmente l’entropie.

6) systemd-resolved échoue avec des boucles de symlink

Symptôme : resolved ne démarre pas ; les erreurs mentionnent la profondeur de symlink de /etc/resolv.conf.

Cause racine : Chaîne de symlink incorrecte, souvent due à la régénération par WSL ou des éditions manuelles superposées aux défauts de la distro.

Correction : Supprimez la boucle et reconstruisez l’état voulu. Assurez-vous d’un seul propriétaire du fichier et que WSL ne le régénère pas contre votre volonté.

7) Les timers tournent quand vous ne le souhaitez pas

Symptôme : CPU/réseau utilisés aléatoirement ; apt-daily s’éveille pendant des démos ; les ventilos hurlent.

Cause racine : Les timers par défaut de la distro ne sont pas conçus pour un environnement laptop dev.

Correction : Désactivez ou replanifiez les timers dont vous n’avez pas besoin. Validez avec systemctl list-timers et vérifiez les logs pour l’impact réel.

Checklists / plan pas-à-pas

Pas-à-pas : activer systemd en sécurité

Confirmer WSL2 : lancez uname -r et cherchez la chaîne noyau WSL2.

Activer systemd dans la distro : éditez /etc/wsl.conf :

cr0x@server:~$ sudo sh -c 'cat > /etc/wsl.conf <<EOF
[boot]
systemd=true
EOF'

Redémarrer l’instance WSL : depuis Windows, terminez la distro ou redémarrez WSL pour appliquer le changement.
Vérifier PID 1 : ps -p 1 -o comm,args.
Vérifier l’état dégradé : systemctl is-system-running, puis systemctl --failed.

Rendre le DNS délibéré : décidez si vous utilisez systemd-resolved. Si non nécessaire, masquez-le et passez à autre chose.

cr0x@server:~$ sudo systemctl mask systemd-resolved.service
Created symlink /etc/systemd/system/systemd-resolved.service → /dev/null.

Désactiver les unités lentes/inutiles : utilisez systemd-analyze blame et désactivez les coupables que vous n’utilisez pas.
Déplacer le travail sensible en performance vers ext4 : gardez les repos/bases de données dans le filesystem Linux, pas sous /mnt/c.

Checklist : setup dev proche de la prod (version saine)

Les services critiques ont des unités systemd avec politiques de restart.
Les logs sont consultés via journalctl, pas « quel que soit le fichier existant ».
La propriété DNS est explicite et documentée.
Les hypothèses réseau entrantes sont testées (depuis Windows et dans WSL).
Les timers sont élagués à ce que vous voulez réellement.
Les dépôts et bases de données résident sur le filesystem Linux.
La chaîne d’outils conteneur a un seul propriétaire (intégration Docker Desktop ou Docker in-distro), pas les deux.

Checklist : quand ne pas vous embêter avec systemd dans WSL

Vous avez juste besoin d’un shell, des compilateurs et de quelques outils CLI.
Votre flux de travail est « lancer un processus au premier plan » et le tuer quand c’est fini.
Vous dépendez de services natifs Windows et n’utilisez WSL que pour des scripts.

FAQ

1) Ai‑je besoin de systemd dans WSL pour utiliser Docker ?

Pas strictement. Docker Desktop peut s’intégrer à WSL sans que vous gériez systemd.
Mais si vous voulez un Docker Engine Linux à l’intérieur de la distro avec une gestion standard par unités, systemd aide.
Choisissez un modèle et engagez‑vous.

2) Pourquoi `systemctl` fonctionne mais mon service ne démarre toujours pas au « boot » WSL ?

Le « boot » WSL est un « démarrage d’instance », et le timing varie. Assurez‑vous que votre unité a les bonnes dépendances et utilisez des checks de readiness.
Ensuite vérifiez systemctl is-enabled et inspectez journalctl -u your.service -b.

3) Dois‑je exécuter systemd-resolved dans WSL ?

Seulement si vous en avez besoin et que vous êtes prêt à prendre en charge explicitement la configuration DNS. Beaucoup d’environnements dev se contentent
de laisser WSL gérer /etc/resolv.conf et de masquer resolved. La pire option est de faire tourner les deux « à moitié ».

4) Pourquoi mes logs manquent sous /var/log ?

Avec systemd, beaucoup de services loggent vers journald, pas vers des fichiers plats. Utilisez journalctl. Si vous voulez des logs fichiers, configurez
le service ou le forwarding journald délibérément.

5) systemd dans WSL est‑il assez stable pour le travail quotidien ?

Oui pour des workflows dev, surtout si vous gardez les configs simples et évitez les pièges de filesystem et DNS.
Non si votre définition de « stable » inclut « se comporte exactement comme notre noyau et réseau de production ».

6) Pourquoi mon service écoute mais est injoignable depuis Windows ?

En général il est lié à 127.0.0.1 dans WSL, ou le firewall/port forwarding Windows a changé. Commencez par ss -lntp et liez délibérément.
Confirmez depuis les deux côtés.

7) Activer systemd va‑t‑il ralentir WSL ?

Ça peut, si votre distro active une foule de services/timers inutiles. La correction est simple : mesurez avec systemd-analyze blame, puis désactivez/masquez le bruit.

8) Puis‑je utiliser les timers systemd à la place de cron dans WSL ?

Oui, et vous devriez probablement le faire. Les timers offrent un meilleur logging et contrôle des dépendances. Souvenez‑vous simplement que si l’instance WSL n’est pas en cours,
les timers ne s’exécuteront pas tant qu’elle ne sera pas démarrée.

9) Quel est le mode de défaillance le plus courant pour systemd‑dans‑WSL ?

Conflits de propriété DNS, suivis par des unités « supplémentaires » lentes ou échouant (snapd, auto-updaters) qui n’étaient pas conçues pour le cycle de vie WSL.

10) Si c’est pour du dev, pourquoi être si strict sur le diagnostic ?

Parce que le downtime dev est du vrai downtime — juste payé en ingénieurs plutôt qu’en clients. Et parce qu’un chemin de diagnostic propre empêche l’équipe
de reproduire des correctifs qui casseront plus tard.

Prochaines étapes concrètes

systemd dans WSL est désormais un outil légitime : vous pouvez gérer des services, obtenir des logs cohérents, et exécuter un environnement dev plus proche de la production
sans bidouilles. Mais WSL garde sa physique propre. Traitez‑le comme un hôte Linux contraint avec Windows comme plateforme — pas comme un petit serveur qui vit sur un laptop.

Étapes pratiques :

Activez systemd, redémarrez WSL, et vérifiez PID 1 + systemctl is-system-running.
Supprimez les services non pertinents : désactivez/masquez ce qui n’a pas sa place dans votre environnement dev.
Choisissez un propriétaire DNS et faites‑le respecter. Les mesures à moitié prises créent les incidents les plus durs.
Déplacez les dépôts/bases de données sensibles aux performances hors de /mnt/c et dans ext4.
Écrivez un petit script « health check » d’équipe qui lance les mêmes 8–10 commandes à chaque fois.

Citation (idée paraphrasée), attribuée : Werner Vogels est souvent crédité du principe selon lequel vous devez « le construire, l’exploiter et l’en assumer la responsabilité »
dans la culture de la fiabilité.

Blague #2 : Si vous masquez snapd dans WSL et que rien ne casse, vous avez découvert la créature la plus rare en ops : une dépendance dont vous n’aviez pas besoin.