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? 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? 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)? Would this be magically resolved by kdbus? >> It does have repercussions. >> >> In GNOME for example, gnome-terminal is started via dbus activation >> (gnome-terminal-server). This means all processes started inside >> gnome-terminal actually are part of >> 4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/user@603.service/dbus.service >> cgroup. > > Yeah, non-converted bus services will appear as part of > dbus.service. That is ugly of course. > > I kinda stopped pushing the per-user stuff until kdbus is done, > because this all resolves itself then, because bus services are then > converted into native systemd services. Does my comment above about the need for the session^H^H^H^H^H user bus to query logind to pick the right session apply? If so, how does that work in a kdbus world? >> Is there any problems that people can think of of running such a setup >> now without any further compartmentalisation or changes? > > Well, it's little tested, and I wish this would just work out of the > box. But again, I am kinda waiting for kdbus to finally be a done deal > before revisiting and pushing for this again... Hmm, bummer. This is working nicely for me on my machine (albeit things in the wrong cgroups etc), but this is sort of a pre-requisite for running PulseAudio via systemd --user socket activation as it needs to talk to the session dbus. It would be a shame to not be able to use that until kdbus lands. I'm tempted to try this but a bit apprehensive as our release is kinda soon and not sure how much testing this would get... I could probably modify my dbus-launch patch to just poke systemd --user env vars and tell it about the DBUS_SESSION_BUS_ADDRESS it creates in the case where it launches dbus-daemon.... there is a race there that PA could still be started before dbus-launch but it's quite unlikely in the normal graphical login case... that might be a half way house and still allow me to use PA socket activation. Ho hum! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
