[BUG] systemd=true causes early wsl.exe -e command timeouts (0x8007274c) during WSL 2 startup

[GoldenSection0618]

Windows Version

Microsoft Windows [Version 10.0.26200.8037]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 22.04

Other Software

Docker Desktop(windows) version: 4.65.0
Docker CLI version: 29.2.1

Repro Steps

1. In /etc/wsl.conf, set:

   [boot]
   systemd=true

2. Run wsl --shutdown.

3. Reboot Windows.

4. Start Ubuntu-22.04.

5. Start Docker Desktop.

6. Docker Desktop fails during WSL integration startup and reports that integration with Ubuntu-22.04 unexpectedly stopped.

Control test:

If I change /etc/wsl.conf to systemd=false, then repeat the same steps, the problem disappears and Docker Desktop starts normally.

Expected Behavior

After the distro starts with systemd=true, wsl.exe -d Ubuntu-22.04 -e ... commands should work reliably during early startup, and WSL integration should not fail.

Actual Behavior

With systemd=true, Docker Desktop consistently fails on the first startup attempt. The failure is reported by Docker as a setup groups error, but the command that actually hangs is:

wsl.exe -d Ubuntu-22.04 -e whoami

That call waits for about 30 seconds and then fails with:

Wsl/Service/0x8007274c

If I click Restart in Docker Desktop, it succeeds immediately afterward. So this looks less like a Docker group configuration problem and more like a WSL exec/session readiness problem during cold startup when systemd=true is enabled.

I also checked whether this was caused by a slow or broken systemd service, but that does not seem to be the case:

• systemd is already in running state
• systemctl --failed is empty
• systemd-analyze blame and critical-chain do not show a 20-30 second stall

Diagnostic Logs

Relevant observations from logs:

• In the failing case, wsl.exe -d Ubuntu-22.04 -e whoami is issued, then times out about 30 seconds later with Wsl/Service/0x8007274c.

• In the successful retry, the same whoami call returns quickly, and the rest of the integration proceeds normally.

• In WSL logs from the failing case, I also saw errors on the internal session / exec path, including messages like:

  • UtilBindVsockAnyPort: bind failed
  • SessionLeaderEntryUtilityVm: InitCreateProcessUtilityVm failed

From my testing, the key trigger is very specific:

• systemd=true -> reproducible failure
• systemd=false -> same machine, same distro, same startup sequence, no failure

This makes it look like a WSL-side problem in the early wsl.exe -e ... execution path when systemd=true is enabled, possibly around session creation / Utility VM / vsock readiness, rather than a generic Linux userspace or Docker group issue.

WslLogs-2026-03-26_14-54-38.zip

docker desktop log.txt

[github-actions]

Diagnostic information

.wslconfig found
Detected appx version: 2.6.3.0
Detected user visible error: Wsl/Service/0x8007274c

[mrjorticio-hash]

Override command and wiperlovked devices and IMAP overall breach of individuals and family accounts leads to collateral damage till wide range of www broadcast

[mrjorticio-hash]

Windows Version

Microsoft Windows [Version 10.0.26200.8037]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 22.04

Other Software

Docker Desktop(windows) version: 4.65.0
Docker CLI version: 29.2.1

Repro Steps

1. In /etc/wsl.conf, set:

   [boot]
   systemd=true

2. Run wsl --shutdown.

3. Reboot Windows.

4. Start Ubuntu-22.04.

5. Start Docker Desktop.

6. Docker Desktop fails during WSL integration startup and reports that integration with Ubuntu-22.04 unexpectedly stopped.

Control test:

If I change /etc/wsl.conf to systemd=false, then repeat the same steps, the problem disappears and Docker Desktop starts normally.

Expected Behavior

After the distro starts with systemd=true, wsl.exe -d Ubuntu-22.04 -e ... commands should work reliably during early startup, and WSL integration should not fail.

Actual Behavior

With systemd=true, Docker Desktop consistently fails on the first startup attempt. The failure is reported by Docker as a setup groups error, but the command that actually hangs is:

wsl.exe -d Ubuntu-22.04 -e whoami

That call waits for about 30 seconds and then fails with:

Wsl/Service/0x8007274c

If I click Restart in Docker Desktop, it succeeds immediately afterward. So this looks less like a Docker group configuration problem and more like a WSL exec/session readiness problem during cold startup when systemd=true is enabled.

I also checked whether this was caused by a slow or broken systemd service, but that does not seem to be the case:

• systemd is already in running state
• systemctl --failed is empty
• systemd-analyze blame and critical-chain do not show a 20-30 second stall

Diagnostic Logs

Relevant observations from logs:

• In the failing case, wsl.exe -d Ubuntu-22.04 -e whoami is issued, then times out about 30 seconds later with Wsl/Service/0x8007274c.

• In the successful retry, the same whoami call returns quickly, and the rest of the integration proceeds normally.

• In WSL logs from the failing case, I also saw errors on the internal session / exec path, including messages like:

  • UtilBindVsockAnyPort: bind failed
  • SessionLeaderEntryUtilityVm: InitCreateProcessUtilityVm failed

From my testing, the key trigger is very specific:

• systemd=true -> reproducible failure
• systemd=false -> same machine, same distro, same startup sequence, no failure

This makes it look like a WSL-side problem in the early wsl.exe -e ... execution path when systemd=true is enabled, possibly around session creation / Utility VM / vsock readiness, rather than a generic Linux userspace or Docker group issue.

WslLogs-2026-03-26_14-54-38.zip

docker desktop log.txt

<<<<<>>>>>

[mrjorticio-hash]

Breach of personal accounts and family accounts