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.
> But obviously the stuff *spawned* by dbus should be within a particular
> session
This is not obvious to me. Anything that can legitimately be used by a
different login session and/or hang around after its originating login
session has finished (e.g. screen, pulseaudio, Telepathy, Rygel, mpd,
...) doesn't really seem like part of that login session any more to me?
I realise there's an oddity here for things that are D-Bus-activated,
but are inextricably linked to one session anyway, because they are X11
applications and cannot outlive their X11 connection (e.g.
gnome-terminal and many other modern GNOME apps).
> Would this be magically resolved by kdbus?
Yes and no...
Yes if your concern is that the services are in dbus' cgroup, because
unlike dbus-daemon, kdbus does not have its own service-activation
mechanism; every service-activation is necessarily a systemd activation.
Compare with dbus-daemon, where a service-activation can go one of two
ways: either it has a corresponding systemd service indicated by
SystemdService and systemd is asked to activate it (and it ends up in
its own cgroup), or it's a traditional D-Bus service and dbus-daemon
does it itself (and it ends up in dbus' cgroup). In kdbus-land,
everything behaves a bit like a member of the former category, and the
latter category can't exist (because there's no dbus-daemon).
No if your concern is that gnome-terminal (or whatever GUI app) is not
part of the cgroup corresponding to its X11 session, because AIUI the
same will be true in kdbus.
>> I kinda stopped pushing the per-user stuff until kdbus is done,
>> because this all resolves itself then, because bus services are then
>> converted into native systemd services.
I don't see anything that strictly requires bus services' conversion
into "systemd --user" services to be blocked by kdbus; someone could
probably even write a generator that produced systemd .service from
D-Bus .service.
I can understand that you don't want the particular generator
implementation in systemd to support that, because it's something of a
non-issue in the absence of kdbus, where dbus-daemon already knows how
to do what it is currently doing; it only becomes a necessary
backwards-compatibility step when dbus-daemon is taken out of the picture.
> I could probably modify my dbus-launch patch to just poke systemd --user
> env vars
Please do not rely on dbus-launch, patched or otherwise, as a medium- or
long-term plan. A future that still contains dbus-launch is not the
world of flying cars I signed up for :-)
S
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
