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

[Colin Guthrie]

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?

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 at 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/