[systemd-devel] how to call dbus ListUnits for user units?

Chris Morgan chmorgan at gmail.com
Tue May 26 13:46:36 PDT 2015

On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas <grawity at gmail.com> wrote:
> On Tue, May 26, 2015 at 10:32 PM, Chris Morgan <chmorgan at gmail.com> wrote:
>> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas <grawity at gmail.com>
>> wrote:
>> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan <chmorgan at gmail.com>
>> > wrote:
>> >>
>> >> But I can't seem to figure out how to do the same for user units.
>> >> There doesn't seem to be an org.freedesktop.systemd1 interface on my
>> >> current user's session bus and I wasn't able to spot anything in the
>> >> interfaces on the system bus that had a nested interface of
>> >> org.freedesktop.system1.Manager...
>> >
>> >
>> > The first "org.freedesktop.systemd1" here is a /service/ name; the usual
>> > hierarchy is bus - service - object - interface - method, no such thing
>> > as
>> > nested interfaces.
>> >
>> > Anyway. The user processes are not allowed to own service names on the
>> > system bus. And `systemd --user` is a per-user service, not a
>> > per-session
>> > one, so it cannot be on the session bus for various reasons: it doesn't
>> > know
>> > the bus address; it needs to outlive the session bus; the user might
>> > sometimes have multiple sessions with their own 'session bus' instances.
>> >
>> > So the idea is that `systemd --user` would be found on the /user/ bus,
>> > which
>> > would someday replace the 'session' bus entirely.
>> >
>> > But right now, the 'user' bus does not exist by default. To create it,
>> > you
>> > need either
>> > a) enable/install/boot with kdbus,
>> > or b) obtain the "dbus.service" & "dbus.socket" user units. (They're in
>> > dbus-git, or various other places like
>> > <https://wiki.archlinux.org/index.php/Systemd/User#D-Bus>.)
>> >
>> > Configured this way, the 'user' bus won't replace the session bus yet,
>> > but
>> > you *will* be able to connect to it and reach systemd, at address
>> > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus".
>> >
>> > --
>> > Mantas Mikulėnas <grawity at gmail.com>
>> Hmm. I guess user services aren't used as much as system ones are?
>> Is there another way to interface with systemctl like functionality
>> programmatically? I have a c application that today is shelling out to
>> systemctl to start services (which is fine for me since I'm not that
>> concerned if it fails but it would be nice to know right at that
> Note that systemctl *does* report failure as the process exit status +
> stderr output.

Yep. But some services fall over after being started (bugs in our code etc).

Does this also apply when doing 'systemctl status blah' eg. a non-zero
exit status if the service isn't running? I'm thinking that may not be

>> time), but once everything is started I'd like to go through the
>> services to make sure they all got started successfully. I didn't want
>> to shell out to 'systemctl --user status xxx' and parse the output....
> Well, systemctl uses a private socket, at $XDG_RUNTIME_DIR/systemd/private.
> It speaks the same DBus protocol, but using a direct peer-to-peer connection
> (it's not a bus address).
> Remember that it's named "private" for a reason -- it's not part of the
> supported API and can go away at any time (e.g. it won't exist anymore with
> kdbus), so use it at your own risk.

Hmm. I guess I'll fall back to parsing the output of systemctl status
until there is some mechanism to interact with user services.

Is support for user dbus manager in the TODO or is that just something
that is waiting on other infrastructure before being implemented? eg.


More information about the systemd-devel mailing list