Discussion:
systemd --user enable: Failed to connect to bus: No such file or directory
(too old to reply)
Bjoern Franke
2018-06-27 06:26:48 UTC
Permalink
Hi,

I'm trying to create a systemd timer for a user to run duply daily. For
one user the enabled worked fine, but another one:

systemctl --user enable backup.timer
Failed to connect to bus: No such file or directory

I have no clue why this happens, systemctl daemon-reload (also with
--user) did not fix it. I found a similar issue in the forums, but the
solution was to "ln -s" the timer and than rebooting. But I don't think
this would be the "correct" solution because "systemctl --user enable"
should also work.

Any hints?

TIA
Bjoern
Ismael Bouya
2018-06-27 06:40:05 UTC
Permalink
Hi Bjoern,
Post by Bjoern Franke
I'm trying to create a systemd timer for a user to run duply daily. For
systemctl --user enable backup.timer
Failed to connect to bus: No such file or directory
I have no clue why this happens, systemctl daemon-reload (also with
--user) did not fix it. I found a similar issue in the forums, but the
solution was to "ln -s" the timer and than rebooting. But I don't think
this would be the "correct" solution because "systemctl --user enable"
should also work.
The two clues I have according to your error are
- Is .config/systemd/user created? (Maybe it has to be created manually)
- Does the second user have dbus started correctly? (for instance, does
"systemctl --user status" work as intended for that user?) Maybe the
second user has a non-working dbus service, or maybe it’s just an
environment variable problem (if I remember correctly, XDG_RUNTIME_DIR
is the variable that should be set correctly to something like
/run/user/<userid>)

Kind regards,
--
Ismael
Bjoern Franke
2018-06-27 09:18:40 UTC
Permalink
Hi Ismael,

thanks for your both hints.
Post by Ismael Bouya
The two clues I have according to your error are
- Is .config/systemd/user created? (Maybe it has to be created manually)
Yes, I've dropped there the timer and service file.
Post by Ismael Bouya
- Does the second user have dbus started correctly? (for instance, does
"systemctl --user status" work as intended for that user?) Maybe the
second user has a non-working dbus service, or maybe it’s just an
environment variable problem (if I remember correctly, XDG_RUNTIME_DIR
is the variable that should be set correctly to something like
/run/user/<userid>)
systemctl --user status has the same error. How do I start dbus for the
second user? systemctl enable --user dbus fails due the same error, and
system's dbus is running.

Thanks
Bjoern
Ismael Bouya
2018-06-27 09:45:11 UTC
Permalink
Post by Bjoern Franke
systemctl --user status has the same error. How do I start dbus for the
second user? systemctl enable --user dbus fails due the same error, and
system's dbus is running.
Good,

Each user + the system has his own dbus. Normally, you should have
dbus.service and dbus.socket units somewhere (/usr/lib/systemd/user
and/or /etc/systemd/user and/or .config/systemd/user)

If it works correctly for one of the users, then probably
/usr/lib/systemd/user and /etc/systemd/user are fine, and there is an
override which breaks the things in .config/systemd/user/dbus.*

Note: If the non-working user is an "old" one, it may be explained by
the fact that those unit files are quite "recent", so probably there is
an history there.

Hope it helps to solve your problem
--
Ismael
Bjoern Franke
2018-06-28 11:02:55 UTC
Permalink
Hi,
Post by Ismael Bouya
Good,
Each user + the system has his own dbus. Normally, you should have
dbus.service and dbus.socket units somewhere (/usr/lib/systemd/user
and/or /etc/systemd/user and/or .config/systemd/user)
If it works correctly for one of the users, then probably
/usr/lib/systemd/user and /etc/systemd/user are fine, and there is an
override which breaks the things in .config/systemd/user/dbus.*
Thanks again for the hints. For both users there are only the
backup.service and backup.timer in .config/systemd/user, no dbus.*
Post by Ismael Bouya
Note: If the non-working user is an "old" one, it may be explained by
the fact that those unit files are quite "recent", so probably there is
an history there.
The working user is older than the non-working user. I took a look into
/etc/systemd/user/sockets.target.wants, dbus.socket is not enabled there.

Regards
Bjoern
Damjan Georgievski via arch-general
2018-06-28 11:39:48 UTC
Permalink
Post by Bjoern Franke
Hi,
I'm trying to create a systemd timer for a user to run duply daily. For
systemctl --user enable backup.timer
Failed to connect to bus: No such file or directory
I have no clue why this happens, systemctl daemon-reload (also with
--user) did not fix it. I found a similar issue in the forums, but the
solution was to "ln -s" the timer and than rebooting. But I don't think
this would be the "correct" solution because "systemctl --user enable"
should also work.
What distro are you running? And what are the versions of systemd and dbus?

You also should have (so confirm that)

/usr/lib/systemd/user/dbus.socket and
/usr/lib/systemd/user/dbus.service files and a
/usr/lib/systemd/user/sockets.target.wants/dbus.socket symlink too
--
damjan
Ralph Corderoy
2018-06-28 12:07:26 UTC
Permalink
Hi Bjoern,
Post by Bjoern Franke
I'm trying to create a systemd timer for a user to run duply daily.
systemctl --user enable backup.timer
Failed to connect to bus: No such file or directory
Are you truly logged in as this second user for whom it does not work,
or just su(1)'d, etc?

My guess is there's a user.service running for the user ID where it
works, and not for the other one. Examine the output of
«systemctl status 'user@*.service'» for dbus-daemon and differences
between the two users.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Bjoern Franke
2018-06-30 11:34:11 UTC
Permalink
Hi Ralph,
Post by Ralph Corderoy
Are you truly logged in as this second user for whom it does not work,
or just su(1)'d, etc?
Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning
an own zsh as user2 would do the right thing.
Post by Ralph Corderoy
My guess is there's a user.service running for the user ID where it
works, and not for the other one. Examine the output of
between the two users.
user.service and user.slice are running for both users.

Regards
Bjoern
Ralph Corderoy
2018-06-30 11:48:24 UTC
Permalink
Hi Bjoern,
Post by Bjoern Franke
Post by Ralph Corderoy
Are you truly logged in as this second user for whom it does not
work, or just su(1)'d, etc?
Erm, just used "sudo -u user2 -s" to login as user2. I assumed
spawning an own zsh as user2 would do the right thing.
It doesn't here. As UID 1000 logged into an XFCE desktop via lightdm,
none of these spring `systemctl status ***@1001.service' into life
since 1001's last `seat' log in on tty7.

sudo -u user2 -s
su - user2
sudo -i -u user2
Post by Bjoern Franke
Post by Ralph Corderoy
My guess is there's a user.service running for the user ID where it
works, and not for the other one. Examine the output of «systemctl
two users.
user.service and user.slice are running for both users.
Maybe that contains dregs from when they were last logged in on a seat?
What about the `Examine... for dbus-daemon and differences between the
two users' above?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Tinu Weber
2018-06-30 11:55:18 UTC
Permalink
Post by Bjoern Franke
Post by Ralph Corderoy
Are you truly logged in as this second user for whom it does not work,
or just su(1)'d, etc?
Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning
an own zsh as user2 would do the right thing.
-s only spawns a regular shell as the user; to get a login shell, it's
`sudo -i`.

That being said, from what I've experienced, sudo on its own (be it with
-s or -i) is not sufficient to control user sessions (I don't know dbus
well enough to explain why, though). What I usually do is:

sudo machinectl --uid user2 shell .host
David Runge
2018-08-01 14:38:59 UTC
Permalink
Post by Tinu Weber
Post by Bjoern Franke
Post by Ralph Corderoy
Are you truly logged in as this second user for whom it does not work,
or just su(1)'d, etc?
Erm, just used "sudo -u user2 -s" to login as user2. I assumed spawning
an own zsh as user2 would do the right thing.
-s only spawns a regular shell as the user; to get a login shell, it's
`sudo -i`.
That being said, from what I've experienced, sudo on its own (be it with
-s or -i) is not sufficient to control user sessions (I don't know dbus
sudo machinectl --uid user2 shell .host
That's also an option, but it's interactive.

If you want to interact with another user's user service (and its dbus
service), you'll have to set the environment variable
DBUS_SESSION_BUS_ADDRESS accordingly (as it might not be in your scope),
or have it available in your current scope.

This boils down to something like:

sudo -u <user> -i
"DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/<user_uid>/bus
systemctl --user <dostuffwithsystemctl>"

I'm sure something similar can be achieved with systemd-run, but I have
not tried.

When looking at `/usr/lib/systemd/user/dbus.socket`, you'll see that it
gets added to the environment there.

systemctl --user cat dbus.socket

Bests,
David
--
https://sleepmap.de
Loading...