Summary

When WSL starts a distribution with systemd enabled, WSL appears to poll systemd before the D-Bus system socket is available.

During otherwise successful startup this produces repeated messages:

Failed to connect to bus: No such file or directory

approximately every 254 ms.

In the case described below, there is no missing user file and no actual startup failure. The messages occur because WSL begins polling systemd before dbus.socket has been created. Once D-Bus becomes available, startup continues normally.

I am proposing an enhancement to make this expected polling behavior less alarming and more informative.

Environment

wsl --version

WSL version: 2.7.12.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.7214
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.9445

Distro: Ubuntu 24.04.4 LTS

/etc/wsl.conf:

[boot]
systemd=true
[user]
default=me
[network]
generateResolvConf = false

Observed behavior

During WSL startup the console contains:

Failed to connect to bus: No such file or directory

repeated many times before normal systemd startup continues.

The corresponding journal entries are:

[    2.638701] WSL (2 - init-systemd(dev1)) WARNING: /etc/resolv.conf updating disabled in /etc/wsl.conf
[    2.932312] Failed to connect to bus: No such file or directory
[    3.186374] Failed to connect to bus: No such file or directory
[    3.439933] Failed to connect to bus: No such file or directory
[    3.693328] Failed to connect to bus: No such file or directory
[    3.947181] Failed to connect to bus: No such file or directory
[    4.201058] Failed to connect to bus: No such file or directory
[    4.454909] Failed to connect to bus: No such file or directory
[    4.708596] Failed to connect to bus: No such file or directory
[    4.962568] Failed to connect to bus: No such file or directory
[    5.216307] Failed to connect to bus: No such file or directory
[    5.470170] Failed to connect to bus: No such file or directory
[    5.723817] Failed to connect to bus: No such file or directory

The interval is consistently about 254 ms.

D-Bus then starts normally:

[    6.349399] systemd[1]: Listening on dbus.socket - D-Bus System Message Bus Socket.
[    6.376040] systemd[1]: Starting dbus.service - D-Bus System Message Bus...
[    6.415413] systemd[1]: Started dbus.service - D-Bus System Message Bus.
[    7.025292] systemd[1]: Startup finished in 4.390s.

systemd-analyze critical-chain dbus.socket confirms that the socket simply has not been reached yet:

dbus.socket @3.714s
└─sysinit.target @3.706s
  └─systemd-resolved.service @3.628s +76ms
    └─systemd-tmpfiles-setup.service @3.609s +16ms
      └─systemd-journal-flush.service @3.252s +274ms
        └─systemd-journald.service @3.199s +44ms
          └─systemd-journald.socket @3.191s
            └─system.slice @3.170s
              └─-.slice @3.170s

The systemd-analyze timestamps are relative to systemd startup. Correlating them with the kernel monotonic timestamps places dbus.socket at approximately 6.349 seconds, exactly where the journal reports it becoming available.

Why the current message is misleading

The text:

Failed to connect to bus: No such file or directory

suggests to users that a required file or directory has been deleted, misconfigured, or was never installed. We see that in other "bug" reports here in Issues.

In this startup sequence that does not appear to be the case. The "file" which does not yet exist is effectively the Unix-domain socket used for D-Bus communication. WSL is attempting to communicate with systemd before systemd has created/listened on that socket.

The failure is therefore an expected intermediate state of the polling operation. It's just being impatient.

In this example:

• systemd starts successfully.
• dbus.socket starts successfully.
• dbus.service starts successfully.
• systemd reports successful startup.
• WSL continues normally.
• There is no WaitForBootProcess timeout.

The repeated error messages appear to be reporting each unsuccessful poll rather than an actual boot failure.

Related reports

There are several existing WSL issues containing the same or closely related message.

#11603 - "Failed to connect to bus: No such file or directory"

This report contains the same repeated message at approximately quarter-second intervals.

In that case polling continues until WSL eventually reports:

/sbin/init failed to start within 10000ms

That is an actual timeout condition and is materially different from the transient polling failures that precede it.

The repeated "No such file or directory" messages may therefore be symptoms of the polling mechanism rather than independent missing-file errors.

#11857 - systemd >= 256 needs plain cgroupv2 support

This report shows:

systemctl is-system-running

initially failing with:

Failed to connect to bus: No such file or directory

and then succeeding on later attempts once systemd has progressed further through startup.

Again, the message can represent "systemd/D-Bus is not ready yet" rather than a permanently missing filesystem object.

#13186 - Failed to start the systemd user session

This report contains many repeated:

Failed to connect to bus: No such file or directory

messages during systemd initialization.

A WSL maintainer subsequently identified the eventual problem as systemd exceeding WSL's boot wait timeout and noted that [boot] initTimeout can control the overall timeout.

This further suggests that the repeated bus messages are polling output leading up to the meaningful condition: either systemd becomes ready or the configured startup timeout expires.

Proposed behavior

During the normal systemd wait period, a failed attempt to reach D-Bus should not be reported as:

Failed to connect to bus: No such file or directory

Instead, if output is considered useful, something informational would better describe what WSL is actually doing, for example:

Waiting for systemd D-Bus socket...

or:

Waiting for systemd to become ready...

I do not think a success message is necessary. If WSL continues startup normally, successful completion of the polling operation is implicit.

If the configured initTimeout expires, WSL can then report the existing meaningful failure:

/sbin/init failed to start within ... ms

That is the point where the temporary polling condition has become an actual startup problem.

Polling interval

The observed polling interval is approximately 254 ms.

For consumer hardware, virtualized filesystems, systems with additional services, security software, or temporarily high host load, it is entirely reasonable for systemd startup to require several seconds.

Polling four times per second does not appear harmful by itself, but reporting every unsuccessful poll as an error creates substantial console noise and makes normal startup look broken. This isn't a bug, it's just bad UX.

Possible approaches would be:

1. Continue polling at the current interval but suppress expected connection failures until initTimeout expires. Only a few seconds is going by, no one will notice pauses, though we easily notice multiple "error" messages.

2. Log the polling condition at debug or informational severity rather than as an apparent error.

3. Emit a single informational "waiting for systemd" message instead of one message for every poll.

4. Optionally expose the polling interval in wsl.conf if there is a reason for users to tune it independently from the existing [boot] initTimeout. Or maybe introduce a highPerformance Boolean that (maybe among other purposes) changes all polls to 250ms when true or 1s when false. By default set it to true so default behavior doesn't change.

The first or third approach would probably resolve the user-facing problem without requiring another configuration option.

Expected behavior

A normal startup where D-Bus is not yet available should not repeatedly present a filesystem-style error.

Expected console behavior could simply be:

Waiting for systemd to become ready...

followed by normal startup output.

Only if initTimeout expires should WSL report a startup failure.

Why this matters

The existing message sends users down the wrong diagnostic path.

Because it says:

No such file or directory

the natural response is to search:

• shell startup scripts
• /etc/fstab
• missing runtime directories
• user permissions
• D-Bus installation
• filesystem corruption
• systemd configuration

In this case (yeah, checked it all) none of those were responsible.

Correlating the monotonic journal timestamps demonstrated that WSL was simply polling before dbus.socket existed, and the socket appeared normally a fraction of a second after the final reported polling failure. This timing condition may explain why people report the issue and then abandon it to Issue auto-close - the issue isn't manually reproducible.

The repeated polling may sometimes be useful evidence that startup is unusually slow, but it should be presented as a waiting/performance condition rather than as a missing-file error. That's why this is an enhancement request and not a bug report.

Thanks!