7

When I attempt to create a new systemd unit (on Ubuntu 16.04)

$ sudo systemctl edit --user --full --force wagoOpenhabBridge.service
Failed to connect to bus: No such file or directory

Apart from this problem my systemd is running fine.
After some internet research, I checked these things:

  • I'm not using docker, Ubuntu is running directly on Intel NUC x64 hardware
  • systemd is running with PID=1
  • XDG variables in env are

    XDGSESSIONID=1790   
    XDGDATADIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop     
    XDGRUNTIMEDIR=/run/user/1000
    

Any ideas what is going wrong? What other things can I check?

1
  • 3
    Why are you using sudo to edit a user unit?
    – muru
    Commented Feb 17, 2018 at 14:17

5 Answers 5

16

I just came across a similar problem, it was caused by trying to run a service as a user I was not logged in with (this user has login disable, and I was using su and sg to fake it).

Why sudo ?

You have probably added sudo because the command was not working, you can safely remove it. A user systemd service is a regular file owned by the regular user.

Fixing Failed to connect to bus: No such file or directory

I found the solution on stackexchange, the DBUS_SESSION_BUS_ADDRESS seems to be missing from your environment.

Your command can be run as this:

export XDG_RUNTIME_DIR="/run/user/$UID"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
systemctl edit --user --full --force wagoOpenhabBridge.service

Running the command before login

If you want the service to be started before the user login, don't forget to run:

sudo loginctl enable-linger USERNAME
4

Solution is install dbus-user-session package (sudo apt install dbus-user-session), reboot and login again.

3

There's another situation in which this happens, namely with a user that is "not properly logged in"... This can happen even if you have no sudo before your command (which shouldn't be there, see other answers).

Check first your $UID and then check if the directory /run/user/$UID actually exists. This might not be the case when for example logging in on a remote machine through one user and then switching to another user (that happen to have no admin rights) by e.g. sudo su some-user.

The systemd system uses polkit for authentication. To be sure that you're logging in as a given user with everything properly set, you can use a tool, machinectl, that can be installed with:

sudo apt install systemd-container

Now login using the password of one of your accounts to get a shell for "some-user" (replace with the proper user name):

machinectl shell some-user@

Now you will see that the directory /run/user/$UID exists, that you can find the XDG environment variables in your shell, and that you can run the systemctl --user commands.

2
  • Wow, this worked! Do you know why regular login (although in multi-seat setup) could have failed to create /run/user/1001 directory, dbus, etc.. ?
    – DimanNe
    Commented Aug 23, 2023 at 8:25
  • I am no expert at this, but one reason I found is that you need to set UsePAM yes in /etc/ssh/sshd_config. Some tutorials recommend disabling it when using public key only login. Commented Nov 14, 2023 at 6:40
0

Is the dbus package installed?

I've noticed a similar issue when running systemctl show $UNIT as a user, with a connection attempted on /var/run/dbus/system_bus_socket which only exists if dbus-daemon --system is running, which itself needs the dbus package to be installed.

You can investigate further by using strace to check what syscalls are performed, and determine which exact issues this Failed to connect to bus: No such file or directory is about. Even if not trying to access the system bus, it's likely to be D-Bus related.

Your systemd package might have dbus in Recommends (that's the case in Debian 9 at least); checking those is usually a good idea when something doesn't work as expected.

0

I had the same error (Failed to connect to bus: No such file or directory) when running the following command on Ubuntu 20.04:

systemctl --user mask tracker-store.service tracker-miner-fs.service tracker-miner-rss.service tracker-extract.service tracker-miner-apps.service tracker-writeback.service

The problem was because of the alias:

alias systemctl='sudo systemctl'

It substituted the systemctl with sudo systemctl and sudo caused the error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .