[systemd-devel] Questions regarding dbus started via systemd --user

Lennart Poettering lennart at poettering.net
Mon Feb 2 14:47:26 PST 2015


On Thu, 08.01.15 14:36, Colin Guthrie (gmane at colin.guthr.ie) wrote:

(Sorry for the late reply. Still busy processing all the queued
mails. I figure half of what this mail was about was already discussed
on the hackfest last friday, but in case something was missing, here
we go)

> Lennart Poettering wrote on 08/01/15 13:19:
> > On Thu, 08.01.15 11:55, Colin Guthrie (colin at mageia.org) wrote:
> > 
> >> Hi,
> >>
> >> I'm just playing around with this and making some progress.
> >>
> >> I've got a modified dbus-launch that can be slotted in nicely to poke
> >> dbus activated via systemd and teach it about the environment for
> >> subsequent launching. It also pokes systemd --user with the environment
> >> too. It's pretty simply and allows for experimentation without too much
> >> impact.
> >>
> >> The issue I currently have is that the dbus daemon itself is now part of
> >> the user at .service cgroup and NOT part of the session cgroup
> >>
> >> i.e. here it is:
> >>
> >> 4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/user at 603.service/dbus.service
> >>
> >> rather than in say:
> >>
> >> 4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/session-c2.scope
> >>
> >> I guess my question is: Is this OK?
> > 
> > Yes, the idea is that these services become singleton services of the
> > user, and the sessions ultimately only retain a "stub" process that
> > does little more than maybe invoke something via systemd and hang
> > around until log out.
> 
> Ahh OK, so this would be a change in the socket activation code in
> systemd --user. Once that works, this might just move over the the
> session?

Note sure I follow on this one. Which socket activation code do you
precisely mean?

> But dbus-daemon itself might be excluded from that no? I mean the model
> is now one-dbus per user and thus it should be shared by all sessions,
> therefore it cannot live within a session itself right?

Well, I mean, we only ever put this altogether for kdbus, where
systemd itself is the one setting up the bus. But yeah, if you want to
make this all work with dbus-daemon, then you would have to teach it
bus activation support. Most likely that should be really easy, and
just involves also installing a dbus.socket and dbus.service into the
user unit dir.

> But obviously the stuff *spawned* by dbus should be within a particular
> session (i.e. dbus would perhaps have to query logind when spawning to
> get the right session - similar in concept to how Kay's patch for polkit
> queries logind to get the current display session)?

No, all stuff should be forked off systemd, and hence be outside of
any immediate user ssession, and instead be a per-user singleton.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list