[arch-general] systemd-run --user does not work

Rodrigo Rivas rodrigorivascosta at gmail.com
Tue May 13 17:04:43 EDT 2014

On Mon, May 12, 2014 at 8:04 PM, Ismael Bouya
<ismael.bouya at normalesup.org> wrote:
> 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?


[0]: http://www.freedesktop.org/wiki/Software/systemd/dbus/

More information about the arch-general mailing list