В Thu, 8 Jan 2015 16:03:43 +0000 Dimitri John Ledkov <dimitri.j.led...@intel.com> пишет:
> 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. > How do you manage things that are inherently per-user and not per-session (like pulse audio, ssh-/gpg-agents)? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
