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

[Andrei Borzenkov]

В Thu, 8 Jan 2015 16:03:43 +0000
Dimitri John Ledkov <dimitri.j.ledkov at intel.com> пишет:

> 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.
> 

How do you manage things that are inherently per-user and not
per-session (like pulse audio, ssh-/gpg-agents)?