On 8 January 2015 at 15:37, Simon McVittie <simon.mcvit...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
