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. <div class="gmail_quote">On Tue, May 26, 2015, 23:46 Chris Morgan <<a href="mailto:chmorgan@gmail.com" target="_blank">chmorgan@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> wrote: > On Tue, May 26, 2015 at 10:32 PM, Chris Morgan <<a href="mailto:chmorgan@gmail.com" target="_blank">chmorgan@gmail.com</a>> wrote: >> >> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> >> wrote: >> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan <<a href="mailto:chmorgan@gmail.com" target="_blank">chmorgan@gmail.com</a>> >> > 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 >> > <<a href="https://wiki.archlinux.org/index.php/Systemd/User#D-Bus" target="_blank">https://wiki.archlinux.org/index.php/Systemd/User#D-Bus</a>>.) >> > >> > 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 <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> >> >> 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 </blockquote></div>