[arch-general] systemd --user enable: Failed to connect to bus: No such file or directory
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
Hi Bjoern,
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.
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
Hi Ismael, thanks for your both hints.
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.
- 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
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
Hi,
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.*
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
On 27 June 2018 at 08:26, Bjoern Franke
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.
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
Hi Bjoern,
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
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
Hi Ralph,
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.
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. user.service and user.slice are running for both users.
Regards Bjoern
Hi Bjoern,
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 user@1001.service' into life since 1001's last `seat' log in on tty7. sudo -u user2 -s su - user2 sudo -i -u user2
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.
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
On Sat, Jun 30, 2018 at 13:34:11 +0200, Bjoern Franke wrote:
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
On 2018-06-30 13:55:18 (+0200), Tinu Weber wrote:
On Sat, Jun 30, 2018 at 13:34:11 +0200, Bjoern Franke wrote:
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 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/
participants (6)
-
Bjoern Franke
-
Damjan Georgievski
-
David Runge
-
Ismael Bouya
-
Ralph Corderoy
-
Tinu Weber