[systemd-devel] Questions regarding dbus started via systemd --user
Dimitri John Ledkov
dimitri.j.ledkov at intel.com
Thu Jan 8 08:03:43 PST 2015
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.
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
More information about the systemd-devel