WSL fails to load certain services when multiple WSL instances are running, and one of them is running as root

[mhegreberg]

Windows Version

tested across multiple versions (like 10.0.22631.5909 and 10.0.19045.6332)

WSL Version

tested across multiple versions (like 2.6.1.0 and 2.5.10.0)

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

tested across multiple versions

Distro Version

tested across multiple versions

Other Software

No response

Repro Steps

if you run Archlinux or tumbleweed(skipping the user creation in OOBE), you end up with a WSL install that uses just the root user, and not other users.

repro:
wsl --install archlinux
wsl --install ubuntu

after install, open both WSL instances, then run systemctl --failed on the second(order doesn't matter)

Expected Behavior

both instances should run correctly

Actual Behavior

certain services fail:

  UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
● console-getty.service loaded failed failed Console Getty
● getty@tty1.service    loaded failed failed Getty on tty1

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'.

[mhegreberg]

I help maintain the Arch WSL image, and have repro'd this with Archlinux Maintainers. (@Antiz96 and @christian-heusel)

[mhegreberg]

WslLogs-2025-10-14_10-33-23.zip

[github-actions]

Diagnostic information

.wslconfig found
	Custom kernel command line found: 'cgroup_no_v1=all systemd.unified_cgroup_hierarchy=1'
Detected appx version: 2.5.10.0

[mhegreberg]

Diagnostic information

I suspect this is unrelated to the bug, as other users may not have had the same config. this was leftover from me testing systemd v258 a few months ago

[OneBlue]

Thank you for reporting this @mhegreberg. The symptoms make sense given that /dev/tty* are devices that are shared at the VM level (so all distros see the same tty devices).

If you're an Arch maintainer, I'd make the case that the best way to solve this would probably to try to get distros to disable the getty and adjacent units in WSL, since they don't provide any value since the user has no easy way to connect to the underlying tty.

Let me know if that would be an option for Arch.

[mhegreberg]

thanks @OneBlue! that seems reasonable to me. I'll try this out.
tracking here: https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/issues/16

[Antiz96]

I help maintain the Arch WSL image, and have repro'd this with Archlinux Maintainers. (@Antiz96 and @christian-heusel)

Hey @mhegreberg,

Thanks once again for the precious help and for taking the time to report this issue! 🤗

Thank you for reporting this @mhegreberg. The symptoms make sense given that /dev/tty* are devices that are shared at the VM level (so all distros see the same tty devices).

If you're an Arch maintainer, I'd make the case that the best way to solve this would probably to try to get distros to disable the getty and adjacent units in WSL, since they don't probably any value since the user has no easy way to connect to the underlying tty.

Let me know if that would be an option for Arch.

Hi @OneBlue,

Thanks for your prompt response, that totally makes sense!

Given your input, I agree there's no point keeping those services enabled (since they indeed probably don't provide any value in a WSL context).

Disabling / masking them in the Arch WSL image sounds like a reasonable plan.

Thanks once again for your help! 🤗

[Antiz96]

We have now merged the "fix" for this on our side (see here).

I guess this issue can be closed. 🙂
Thanks once again for the help! 🤗 🙏

[mhegreberg]

I suspect that it would be good for other distros to implement the same fix, in case their users choose to run as root, but the fix from our side works

[Jason-Fajardo]

Shouldn't the first instance be the controller/ If you can keep note of what service the master thread starts? And any future instances can communicate with existing required services and doesn't force any service to crash.......