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 <chmor...@gmail.com> wrote: > On Tue, May 26, 2015 at 4:05 PM, Mantas Mikulėnas <graw...@gmail.com> > wrote: > > On Tue, May 26, 2015 at 10:32 PM, Chris Morgan <chmor...@gmail.com> > wrote: > >> > >> On Tue, May 26, 2015 at 3:22 PM, Mantas Mikulėnas <graw...@gmail.com> > >> wrote: > >> > On Tue, May 26, 2015 at 9:33 PM, Chris Morgan <chmor...@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 <graw...@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 >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
