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

[Dimitri John Ledkov]

On 8 January 2015 at 15:37, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> On 08/01/15 14:36, Colin Guthrie wrote:
>> Lennart Poettering wrote on 08/01/15 13:19:
>>> Yes, the idea is that these services become singleton services of the
>>> user, and the sessions ultimately only retain a "stub" process
>>
>> 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?
>
> I think you might be misunderstanding what Lennart said, since you seem
> to both have the same model in mind, which is: even if I am logged in
> via gdm and via ssh and via getty (3 sessions), there is one systemd
> --user associated with my uid (which is not part of any of those
> sessions), and one dbus-daemon --session (likewise), and one gpg-agent,
> and presumably one PulseAudio, and whatever other misc services are
> needed in the background.
>

Hm, this is interesting. Since 14.04, Ubuntu uses upstart to manage
user sessions. At the moment it is for graphical sessions only,
however the semantics are different.

There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions, one has three
upstarts running, three dbus (with different bus ids), etc.

Thus my expectation would be to have a systemd (dbus, etc...) --user
per-session/per-seat, rather than per-uid.

In Ubuntu, we are yet to flash out how to migrate upstart user
sessions to systemd user sessions, for the time being we are
preserving upstart user sessions, even if systemd is pid1.


-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.