[PID 1 Error] "failed to connect to bus: no such file or directory" Windows 10, WSL 2, Debian - possible fix detailed

[The-Monkey-King]

Windows Version

Microsoft Windows [Version 10.0.19045.3208]

WSL Version

1.3.14.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux 5.15.90.3-microsoft-standard-WSL2

Distro Version

Debian 12

Other Software

No response

Repro Steps

1. Fresh install of WSL
2. Set WSL to version 2
3. Install Debian from Microsoft Store
4. Clicked 'Open' from Debian Store page and installed/configured login/password
5. Closed Debian window
6. Opened Terminal (previously installed)
7. From Terminal, opened a tab to the Debian instance
8. Added file to Debian instance: sudo nano /etc/wsl.conf with: [boot] systemd=true (two separate lines)
   Saved file, exited nano
9. Closed Debian tab
10. In the Terminal tab, I ran wslconfig /t Debian to kill Debian instance.
11. Ran wsl --shutdown to shut down WSL
12. Closed Terminal
13. Opened Terminal again and added Debian as the second tab.
14. In Debian I ran systemctl list-units --type=service and received error message, Failed to connect to bus: No such file or directory.
15. Checked wsl.conf in Debian as correct. Checked wsl and Debian for any other issues, none found.

This error can be replicated faithfully.

Expected Behavior

Running systemctl list-units --type=service should return the list of services loaded or not and active or not.

I tried modifying wsl.conf with additional entries of [automount], [interop], and [network]. Then killed the Debian instance, shut down WSL. Yes, I even physically turned the PC off and on. But systemd appears not to be running.

Actual Behavior

Instead of getting a list of services, I get the error message, failed to connect to bus: no such file or directory. I can work inside the instance like normal except no services are running. When I try to run a script or process, I get the System has not been booted with systemd as init system (PID 1) error.

POSSIBLE FIX
HOWEVER - Scouring the web, I did find this tidbit from github user, alyleite about running systemd earlier in the boot process?

After deleting everything and starting fresh again. I added these two commands after Step 8 and before Step 9 in the Repro Steps above. I kept wsl.conf to just the [boot] section.

First command in the Debian tab of Terminal:
sudo apt-get update && sudo apt-get install -yqq daemonize dbus-user-session fontconfig

This added and updated files in the Debian instance and completed successfully.

Second command, same tab:
sudo daemonize /usr/bin/unshare --fork --pid --mount-proc /lib/systemd/systemd --system-unit=basic.target

It completed successfully without any other messages. I tried to run exec sudo nsenter -t $(pidof systemd) -a su - $LOGNAME but my Debian instance did not know nsenter, I continue with steps 9-14 but this time systemctl returns the proper response. Even after I restart my PC, the Debian instance behaves normally.

Diagnostic Logs

Running a log after it appears to be working will not add anything, I believe.

AFAIK (or see) the commands do two things. First command updates dbus-user-session and daemonize. Second command then basically restructures systemd to start earlier in the boot-up process? (Sorry, Linux is like a second language to me right now. So I am guessing at this point.)

But it does work. And I can repeat it on at least my machine.

[elsaco]

@The-Monkey-King install dbus and dbus-user-session packages. For some reason (unknown to me) this packages are not part of the Debian distro pulled from the store.

From apt info systemd output:

Recommends: default-dbus-system-bus | dbus-system-bus

[ghost]

If you take elsaco's advice and it still doesn't work, send /logs.

[microsoft-github-policy-service]

Hello! Could you please provide more logs to help us better diagnose your issue?

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 scipt will output the path of the log file once done.

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

Click here for more info on logging

Thank you!

[The-Monkey-King]

Interesting. Just installed Debian. After first running sudo apt update, I ran apt info systemd and received the following recommends:
Recommends: default-dbus-system-bus | dbus-system-bus, systemd-timesyncd | time-daemon

I want to see if the suggested path fixes the issue first, but I am concerned that a time sync is not enabled either.

UPDATE: Installing dbus and dbus-user-session recommends I install a time package, too. But I am going ahead with just dbus for now and if it fixes it, I will install the latter after all else.

[The-Monkey-King]

The recommend installation of the missing dbus elements worked. I'd rather not close this defect until I can get the Microsoft WSL / Debian team(s) to install dbus and dbus-user-session at first installation -- even if a user does not want/need systemd to be running.

What are my next steps to seeing this gets resolved at base installation?

[ghost]

You'll need to file this against the Debian folks. We don't maintain any of the distros. With very few exceptions we don't make changes that reach inside and modify a users distribution. That's an easy pattern to make mistakes with.

File against https://www.debian.org/Bugs/Reporting. Unless @craigloewen-msft has another suggestion for reaching out to Debian.

[lorengordon]

After following the rabbit hole down a bunch of other ideas, simply sudo apt install dbus-user-session worked for me also. Exited and shutdown WSL, started a new session, and now /run/user/1000/bus exists and apps looking for it (vscode, firefox) are no longer complaining about its absence.

[karJac]

For me the problem was solved by doing this:

[10569:0827/004757.735915:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: No such file or directory

can be fixed by adding these lines to ~/.bashrc

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
    dbus-daemon --session --address=unix:path=/run/user/1000/bus --fork
    export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
fi

The issue is that when running program, it expects the socket to be located at a fixed path in /run/user/1000/bus, which doesn't work in WSL2 where the socket is instead created as an abstract socket and is found under /tmp

dbus-launch --sh-syntax --exit-with-session
DBUS_SESSION_BUS_ADDRESS='unix:abstract=**/tmp/dbuslADZpPMOKJ,guid=55593467f737024f5f2ed7c566cd08fd**';
export DBUS_SESSION_BUS_ADDRESS;
DBUS_SESSION_BUS_PID=11021;
DBUS_SESSION_BUS_WINDOWID=6291457;