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

Mantas Mikulėnas grawity at gmail.com
Tue May 26 14:02:42 PDT 2015


Well, the systemd side is already there – if you have kdbus, it'll create a
user bus there, and if you have traditional dbus.service + dbus.socket,
systemd will also happily connect to that.

On Tue, May 26, 2015, 23:46 Chris Morgan <chmorgan at gmail.com> wrote:

> 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
> likely.
>
>
> >>
> >> 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.
> kdbus?
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150526/1854903a/attachment-0001.html>


More information about the systemd-devel mailing list