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/