On Mon, May 12, 2014 at 8:04 PM, Ismael Bouya
<ismael.bouya@xxxxxxxxxxxxxx> 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?
--
Rodrigo
[0]: http://www.freedesktop.org/wiki/Software/systemd/dbus/
