Regression in v2.6.1.0: WSL2 shuts down despite active systemd service

[pmyers]

Windows Version

Microsoft Windows [Version 10.0.26120.5751]

WSL Version

2.6.1.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Fedora release 42 (Adams)

Other Software

No response

Repro Steps

Environment
This is a confirmed regression, tested on two machines with the identical Windows build.

Working Environment

WSL Version: 2.5.10.0

Windows Version: 10.0.26120.5751

Failing Environment

WSL Version: 2.6.1.0

Windows Version: 10.0.26120.5751

Problem Description
On WSL version 2.6.1.0, the WSL2 VM instance shuts down approximately 15-20 seconds after the last terminal window is closed, even when a systemd service is in a stable active (running) state.

This behavior does not occur on the older WSL version 2.5.10.0 on the exact same Windows build, where the instance correctly remains active.

Steps to Reproduce
Ensure you are running WSL version 2.6.1.0 or later on a system with systemd=true enabled in /etc/wsl.conf.

Create a minimal systemd system service file at /etc/systemd/system/keep-alive.service:

[Unit]
Description=Test service to keep WSL active

[Service]
ExecStart=/bin/sleep infinity

[Install]
WantedBy=multi-user.target

Enable and start the service: sudo systemctl enable --now keep-alive.service.

Verify the service is active and stable: sudo systemctl status keep-alive.service.

Close all open WSL terminal windows.

Open a new PowerShell terminal and monitor the output of wsl -l -v.

Expected Behavior
The WSL instance should remain in the Running state indefinitely, as long as the keep-alive.service is active. This is the behavior seen in WSL version 2.5.10.0.

Actual Behavior
The WSL instance changes from the Running state to the Stopped state within 15-20 seconds after the last terminal is closed.

Additional Context
This is a confirmed regression. I reproduced this issue by upgrading a machine from the working v2.5.10.0 to the failing v2.6.1.0. The issue appeared immediately after the upgrade.

Troubleshooting has confirmed this is not a user configuration issue. There is no .wslconfig file in use, and /etc/wsl.conf is standard. The issue occurs with any systemd system service, not just a specific one.

Expected Behavior

I'd expect the same behavior on 2.6.1.0 as seen in 2.5.10.0, which is a running and active systemd service prevents WSL2 from shutting down the instance even after all running terminals are closed.

Actual Behavior

On 2.6.1.10 after about 20 seconds, WSL2 shuts down the instance after the last terminal is closed even though there is a running and active systemd service.

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[pmyers]

/question

Regarding getting logs for this via collect-wsl-logs.ps1 as required...

I cannot reproduce the issue when that log script is running, as it appears the log script itself is keeping WSL2 from terminating the instance. I can reproduce it 100% of the time, but only when that logging script is not running.

I debugged your collect logs script and found that as long as there is an active wpr.exe -start running in the background, WSL2 will not exit the instance. But as soon as wpr.exe -stop is run, it will exit shortly afterwards.

This means that the debugging tool (the log collection via wpr.exe) is itself influencing the results, and therefore we can't use this debugging tool to capture results (at least not the way the ps1 script is currently invoking it).

If you have some other advice for how to capture logs here, without having the log capture influence the reproducibility of the issue, please advise.

[ctykk]

try https://github.com/gardengim/keepwsl

[pmyers]

Thanks @ctykk. I already had something very similar to this installed and running, and that worked fine to keep WSL2 alive in the past. But I also have other persistent systemd services like open-webui and insync running as well, so those should have also helped keep WSL2 alive. As mentioned, I've shown that this is a regression between the current release (2.5.10.0) and the preview release (2.6.1.0).

[magicdude4eva]

Frustrating that this issue exists, any view when this can be resolved? Really pointless to have a distro running with docker and other system services and it terminates.

[magicdude4eva]

Update: I downgraded to 2.5.10 and can re-produce this also on 2.5.10. Details:

WSL-Version: 2.5.10.0
Kernelversion: 6.6.87.2-1
WSLg-Version: 1.0.66
MSRDC-Version: 1.2.6074
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.22631.5909

Services and dockerd start when entering the distro wsl -d wsl-containers-0.2.0:

dev@NBW06723:/mnt/c/development/backbone/etc/docker-compose$ systemctl status docker
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/docker.service.d
             └─override.conf
     Active: active (running) since Wed 2025-10-15 09:08:21 CEST; 34s ago
 Invocation: 2d7b729827ed4df3a14e8df7d05e91ac
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 123 (dockerd)
      Tasks: 135
     Memory: 135M (peak: 446.3M)
        CPU: 9.738s
     CGroup: /system.slice/docker.service
             ├─ 123 /usr/bin/dockerd
             ├─ 962 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 9000 -container-ip 172.17.0.2 -container-port 9000 -use-listen-fd
             ├─ 971 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 9000 -container-ip 172.17.0.2 -container-port 9000 -use-listen-fd
             ├─1006 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 7002 -container-ip 172.19.0.3 -container-port 7002 -use-listen-fd
             ├─1013 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 7002 -container-ip 172.19.0.3 -container-port 7002 -use-listen-fd
             ├─1020 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 17002 -container-ip 172.19.0.3 -container-port 17002 -use-listen-fd
             ├─1028 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 17002 -container-ip 172.19.0.3 -container-port 17002 -use-listen-fd
             ├─1060 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 7001 -container-ip 172.19.0.2 -container-port 7001 -use-listen-fd
             ├─1067 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 7001 -container-ip 172.19.0.2 -container-port 7001 -use-listen-fd
             ├─1075 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 17001 -container-ip 172.19.0.2 -container-port 17001 -use-listen-fd
             ├─1083 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 17001 -container-ip 172.19.0.2 -container-port 17001 -use-listen-fd
             ├─1118 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 7000 -container-ip 172.19.0.4 -container-port 7000 -use-listen-fd
             ├─1124 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 7000 -container-ip 172.19.0.4 -container-port 7000 -use-listen-fd
             ├─1132 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 17000 -container-ip 172.19.0.4 -container-port 17000 -use-listen-fd
             └─1139 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 17000 -container-ip 172.19.0.4 -container-port 17000 -use-listen-fd

Also on 2.5.10.0 the distro shuts down when exiting the distro shell:

$ date; wsl -l -v
Wed Oct 15 09:10:01     2025
  NAME                    STATE           VERSION
* wsl-containers-0.2.0    Running         2
[1]+  Done                    date
$ date; wsl -l -v
Wed Oct 15 09:10:08     2025
  NAME                    STATE           VERSION
* wsl-containers-0.2.0    Running         2

....

$ date; wsl -l -v
Wed Oct 15 09:12:02     2025
  NAME                    STATE           VERSION
* wsl-containers-0.2.0    Running         2

$ date; wsl -l -v
Wed Oct 15 09:12:03     2025
  NAME                    STATE           VERSION
* wsl-containers-0.2.0    Stopped         2

Reproduced this in the logs:
09:33:20 - brought up distro via wsl -d wsl-containers-0.2.0

$ date; wsl -l -v
Wed Oct 15 09:33:25     2025
  NAME                    STATE           VERSION
* wsl-containers-0.2.0    Running         2

Containers are running and after docker ps exited the distro

$ docker ps
CONTAINER ID   IMAGE                            COMMAND                   CREATED          STATUS                    PORTS                                                                                                    NAMES
8af1f8e5ce3d   portainer/portainer-ce:latest    "/portainer"              25 minutes ago   Up 10 seconds             8000/tcp, 9443/tcp, 0.0.0.0:9000->9000/tcp, [::]:9000->9000/tcp                                          portainer
58920b90b0f9   nexus.eurofunk.com/redis:5.0.0   "/bin/sh -c 'echo \"$…"   26 minutes ago   Up 10 seconds (healthy)   0.0.0.0:7000->7000/tcp, [::]:7000->7000/tcp, 6379/tcp, 0.0.0.0:17000->17000/tcp, [::]:17000->17000/tcp   redis1-eocs
36dbdb2d874c   nexus.eurofunk.com/redis:5.0.0   "/bin/sh -c 'echo \"$…"   26 minutes ago   Up 10 seconds (healthy)   0.0.0.0:7001->7001/tcp, [::]:7001->7001/tcp, 6379/tcp, 0.0.0.0:17001->17001/tcp, [::]:17001->17001/tcp   redis2-eocs
a942590d405d   nexus.eurofunk.com/redis:5.0.0   "/bin/sh -c 'echo \"$…"   26 minutes ago   Up 10 seconds (healthy)   0.0.0.0:7002->7002/tcp, [::]:7002->7002/tcp, 6379/tcp, 0.0.0.0:17002->17002/tcp, [::]:17002->17002/tcp   redis3-eocs

$ exit
logout

At 09:33:44 the distro stops:

$ date; wsl -l -v
Wed Oct 15 09:33:44     2025
  NAME                    STATE           VERSION
* wsl-containers-0.2.0    Stopped         2

Log-file
WslLogs-2025-10-15_09-14-11.zip

[magicdude4eva]

To rule out any regressions, I validated this behaviour also in

WSL-Version: 2.4.13.0
Kernelversion: 5.15.167.4-1
WSLg-Version: 1.0.65
MSRDC-Version: 1.2.5716
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.22631.5909

To reproduce, install Ubuntu 22.04 and docker - install steps:

wsl --install -d Ubuntu-22.04

notepad %USERPROFILE%\.wslconfig
[wsl2]
# Force systemd to use legacy cgroup v1 for better compatibility with Docker and WSL2
kernelCommandLine = "systemd.unified_cgroup_hierarchy=0"

#
wsl --shutdown
wsl -d Ubuntu-22.04

# Docker
# Update packages
sudo apt update && sudo apt upgrade -y

# Install dependencies
sudo apt install -y ca-certificates curl gnupg

# Add Docker’s official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add Docker repository
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker Engine
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Enable and start Docker service
sudo systemctl enable docker
sudo systemctl start docker


#
sudo systemctl status docker

Exit the interactive shell and do "wsl -l -v" and you will see that after 15 seconds the distro stops:

 $ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
$ wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2

FWIW - a "keep-alive" service keeps the distro up:

sudo bash -c 'cat > /etc/systemd/system/keep_alive_wsl.service <<EOF
[Unit]
Description=keepwsl.service

[Service]
ExecStart=/mnt/c/Windows/System32/wsl.exe --exec sh -c "sleep infinity"
Type=simple
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF'

sudo systemctl daemon-reload
sudo systemctl enable --now keep_alive_wsl
sudo systemctl start keep_alive_wsl

[nebulon42]

For me on Windows 10.0.22631.5909 and WSL 2.5.10.0 a fresh Ubuntu with systemd=true in /etc/wsl.conf (by default) with the Docker sytemd service running and a container with docker run -d --name keep-alpine --restart unless-stopped alpine:3.20 sleep infinity also exits after closing the terminal.

Edit: I read that this behavior might be by design although surprising.