On Thu, 08.01.15 14:36, Colin Guthrie (gm...@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 (co...@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@.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@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
