[arch-general] systemd-run --user does not work
Hello, list! This is an issue that has been nagging me for a while, and I thought that it was something I did to my machine, until I tested it in another Arch installation, and it is all the same. The problem is when I run for example: $ systemd-run --user /usr/bin/ls Failed to create bus connection: No such file or directory I would expect it to run the command and save the output in the journal, just as the --system counterpart does. You could think that the systemd user daemon is not running properly, but: $ systemctl --user works perfectly. Moreover, if I create a user unit as ~/.config/systemd/user/test.service and start it with `systemctl --user start test` it works, too. I know that systemd user sessions are still a bit of experimental, but I don't see any reason why systemctl works and systemd-run does not. Is this a bug? Or am I missing something? -- Rodrigo
On Mon, May 12, 2014 at 11:17 PM, Rodrigo Rivas wrote: Hello, list! This is an issue that has been nagging me for a while, and I thought
that it was something I did to my machine, until I tested it in
another Arch installation, and it is all the same. The problem is when I run for example: $ systemd-run --user /usr/bin/ls
Failed to create bus connection: No such file or directory I would expect it to run the command and save the output in the
journal, just as the --system counterpart does. You could think that the systemd user daemon is not running properly, but: $ systemctl --user works perfectly. Moreover, if I create a user unit as
~/.config/systemd/user/test.service and start it with `systemctl
--user start test` it works, too. I know that systemd user sessions are still a bit of experimental, but
I don't see any reason why systemctl works and systemd-run does not.
Is this a bug? Or am I missing something? --
Rodrigo Well, I just tried this out on my laptop, and it gives two different error
messages.
$ sysytemd-run --user /usr/bin/ls
Failed to create message: Input/output error
$ sudo systemd-run --user /usr/bin/ls
Failed to create bus connection: Connection refused
And yes, running it with --system works perfectly well. It is very odd.
--
Savyasachee Jha
*"Aerodynamics is for people whodon't know how to build engines."*
(Mon, May 12, 2014 at 11:23:33PM +0900) Savyasachee Jha :
Well, I just tried this out on my laptop, and it gives two different error messages.
$ sysytemd-run --user /usr/bin/ls Failed to create message: Input/output error
$ sudo systemd-run --user /usr/bin/ls Failed to create bus connection: Connection refused
And yes, running it with --system works perfectly well. It is very odd.
(This answer is a summary of a tutorial that I wrote some days ago and you can find the french version here: http://immae.eu/blog/2014/05/10/gerer-sa-session-avec-systemd/ If you don't speak french, be patient, I'm working on its translation) For me it works both with user and system. It works for system: That's normal, because systemd makes use of dbus, and the system bus is always there, and he knows where to contact it. However, systemd-run --user tries to contact the "user dbus" (AKA session dbus), via your "systemd --user" (You can see it with "pstree -aUp login" if it is started. If it is not, then probably you should enable the correct module via pam). Does this process know your dbus session? If you didn't do anything regarding that, then certainly not. You can be sure by checking its environment which should contain something like that: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus Let's say you don't have it in "systemd --user". Simply add something like that in /etc/systemd/system/user@.service.d/dbus_env.conf -------- [Unit] Wants=dbus.service [Service] Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus --------- and follow the DBUS section there: https://wiki.archlinux.org/index.php/Systemd/User#D-Bus This will ensure that you have a dbus session and that all the services (including systemd --user) know how to have access to it. Then you can run your systemd-run --user. You have to restart *all* your sessions before that of course (I.e. you muss not have any remaining session at your name, otherwise the process won't end. Check that with systemd-cgls or so. If you enabled lingering sessions then you probably don't have this problem, otherwise make sure everything is killed) (Note that your shell doesn't have to know the DBUS_SESSION_BUS_ADDRESS variable) -- Ismael
On Mon, May 12, 2014 at 8:04 PM, Ismael Bouya
For me it works both with user and system.
[skip instructions]
(Note that your shell doesn't have to know the DBUS_SESSION_BUS_ADDRESS variable)
Thank you!! I have followed your instructions and it actually works, although I have to run: $ export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus before being able to run systemd-run. What I don't understand is why. Why "systemd-run" needs the dbus-session daemon while "systemctl" works perfectly fine without it? Both programs ultimately call to the same interface [0], don't they? After some investigation, it looks like the user systemd daemon creates a private dbus address in "/run/user/$(id -u)/systemd/private". Then, systemctl uses this private socket, while systemd-run uses the standard, session, dbus-daemon, if the systemd user daemon is able to connect to it (that's where I had failed but Ismael succeeded). Now, my question is: Why doesn't systemd-run use the private socket address, just as systemctl does? And now that we are into it, why is a separated program? Why not "systemctl run" or "systemctl transient-run"? Maybe too many different command-line options? Just to prove my point I managed to create a user transient unit without using the session bus, running this command: $ gdbus call -a unix:path=/run/user/$(id -u)/systemd/private -o /org/freedesktop/systemd1 -m org.freedesktop.systemd1.Manager.StartTransientUnit \ run-$RANDOM.service fail \ "[('ExecStart', <[('/usr/bin/ls', ['/usr/bin/ls','-l'], false)]>)]" \ "[]" Yes... it took me a while to get the right syntax ;-) Maybe I should move this as a request for upstream? -- Rodrigo [0]: http://www.freedesktop.org/wiki/Software/systemd/dbus/
Hi, I don't know if it's necessary to send the request upstream for the moment: They are busy moving things to kdbus (which is the kernel implementation of dbus, and not "KDE-dbus" as I thought initially). Things are actually slightly messed up currently (that's my opinion, when I spent time reading the systemd code to write my tutorial). The best thing to be sure that everything works is to make sure that all of your processes have the information about DBUS_SESSION_BUS_ADDRESS, and the same information (and that dbus --session is started also, of course). Some processes spawn a dbus when they cannot find one, which makes things harder to debug (because they won't complain but it won't work as expected as they will have their own bus and noone can talk to them. And you end with two dbus processes just for you) About the difference between systemd-run and systemctl: I didn't have a close look at the systemd-run code, but they seem to have a different way of implementing dbus connections (which might come from the comment above, or simply legacy code). And I also ran into trouble with systemctl when I didn't have the DBUS part (I cannot remember which kind of problems, but that's where I started to dive into details of systemd implementation) So to sum up: if you have it everywhere it works; so why not put it and forget about it (it's not so hard to ensure actually). -- Ismael
Now I understand why sometimes I have two dbus daemons, thanks ! It's because I manage tmux with systemd --user, and $DBUS is set by my xorg session not managed by systemd. In fact, why isn't there a user unit for dbus by default ?
(Wed, May 14, 2014 at 09:45:40AM +0200) Yamakaky :
Now I understand why sometimes I have two dbus daemons, thanks ! It's because I manage tmux with systemd --user, and $DBUS is set by my xorg session not managed by systemd.
Watch out about that. It's tempting to have your tmux managed by systemd services (did you enable "lingering" to be sure that it doesn't get killed when you exit your sessions?). And I do too. However, to make it simple, a shell "part of a service" is not equivalent to a shell "in the session scope of the user", so you should expect problems with that (if you ever get lost, the command "systemd-cgls" is a good way to find out in which kind of scope your processes are). In particular, a service is never considered "active" by systemd, and this can create problems when in interaction with polkit (for instance), where the same command ("shutdown" is the best known example) will be accepted without needing sudo in a regular shell while it will be refused in a shell "part of a service". I don't say of course that you shouldn't do it, just keep in mind that it's not equivalent :p
In fact, why isn't there a user unit for dbus by default ?
That's a good question! -- Ismael
I don't say of course that you shouldn't do it, just keep in mind that it's not equivalent :p
I know, thanks, I already had similar problems with gpg-agent. I solved this problem with `After=gpg-agent.service` in tmux.service. It's not perfect, but it seems to work.
On Tue, May 13, 2014 at 11:57 PM, Ismael Bouya
Hi,
I don't know if it's necessary to send the request upstream for the moment: They are busy moving things to kdbus (which is the kernel implementation of dbus, and not "KDE-dbus" as I thought initially).
Anyway, I finally managed to send a bug report upstream [1], and a quick fix seems to be on the way. Cheers! [1]: https://bugs.freedesktop.org/show_bug.cgi?id=79252
On Tue, May 13, 2014 at 3:04 AM, Ismael Bouya
[snip-explanation] -- Ismael
Thank you, Ismael. I've not yet implemented what you've suggested (been a bit busy), but I'll report back once I get the time to play with my laptop. I'm certain it works, as your explanation makes a lot of sense. -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*
participants (4)
-
Ismael Bouya
-
Rodrigo Rivas
-
Savyasachee Jha
-
Yamakaky