On 18/02/13 19:08, Kok, Auke-jan H wrote:
> On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie
> <simon.mcvit...@collabora.co.uk> wrote:
>> It looks as though the intention is [...]
>> I have one XDG_RUNTIME_DIR, one 'systemd
>> --user' instance (as per systemd's TODO: started by logind using
>> user@.service, on behalf of pam_systemd) and one 'dbus-daemon --session'
>> instance (presumably started by that 'systemd --user').
>
> Ideally, we'd have one `systemd --user` survive throughout the entire
> sequence.
>
> I believe that the DBus bits are properly in place to have one single
> user bus per user session.
To be completely clear: what exactly do you mean by "per user session"
here? Is a "user session" a login1.Session, or a login1.User?
If I upstream the dbus.service, dbus.socket from user-session-units into
dbus, then we have exactly one `dbus-daemon --session` per `systemd
--user`. If one `systemd --user` spans the whole lifetime of a
login1.User, that's one `dbus-daemon --session` across one or more login
sessions:
:0 :1
------------- /dev/tty1 -------------- X login session
-------------------------- getty login session
========================================== XDG_RUNTIME_DIR
========================================= systemd --user
======================================== dbus-daemon --session
(In that diagram, ---- is login1.Session-scoped, ==== is
login1.User-scoped.)
I don't think it's particularly useful to do that upstreaming until we
have a reasonable answer for how DISPLAY gets copied around.
logind doesn't currently track XAUTHORITY alongside DISPLAY, but perhaps
it should (or perhaps GDM should always put users' Xauthority databases
in their XDG_RUNTIME_DIR).
> For each login, you'd have an instance service (e.g.
> gnome-session@:0.service) to serve that display.
I'm not sure how much that would actually help. GDM and other display
managers currently consider the lifetime of the session to be defined by
the lifetime of a process (which, for GNOME, is gnome-session). In
principle it would be possible to make that process be "start
gnome-session@:0.service on the user systemd, and when it exits, exit",
but I'm not sure that really gains us anything over GDM just running
gnome-session! It seems more useful to get session D-Bus services
systemd-activated, then use those whenever possible (so that systemd
--user can run them on-demand, perhaps starting as soon as the PAM
session opens).
The next step might be to have a way for XDG applications (.desktop
files) - or at least those that are one-at-a-time-per-user - to be
systemd-activated, so that application launching happens through the
user systemd.
Having a `systemd --user` survive across multiple sessions does conflict
with user-session-units' current assumptions: it would imply that
default.target (or whatever target user@.service runs) cannot usefully
depend on anything that's a GUI. xorg.target would also have to change
(cope with an X11 display being passed in from outside the session, or
be instanced, or something), but that's true for GDM anyway.
>> Is there any plan for how GUI processes started via session D-Bus
>> activation should pick up the right value for $DISPLAY?
>
> GUI processes running under a gnome-session@:0.service should be able
> to getenv(DISPLAY) if it's set by gnome-session@.service
> (Environment=DISPLAY=%I).
I thought the idea of `systemd --user` was to reduce the set of
processes running under (as in child processes of) gnome-session,
ideally to 0? :-)
> but yeah, no answer for dbus activated services.
I've started prototyping what would be needed for `systemd --user` to
track logind sessions, pick up the new $DISPLAY every time the user's
set of sessions changes, and use that for all new activations.
If not every session D-Bus service is a systemd user service, then
dbus-daemon would need to do more or less the same (but in any case, the
goal ought to be that every session D-Bus service is also a systemd user
service, I think).
>> If there is not currently a plan for how to deal with DISPLAY and
>> XAUTHORITY, I think they could be solved by having 'systemd --user'
>> watch logind, and include those variables (or perhaps only DISPLAY?)
>> from the corresponding uid's most-recently-started X11 session? (I
>> believe GDM only supports one simultaneous X11 session per uid anyway.)
>
> even for multiseat?
No, you're right, it's one per (uid, seat) pair. So for multi-seat
setups there'd certainly have to be some concept of "best X11 display"
(most recently started?) in the environment of new activations.
I wonder how much breaks when two X11 displays share a session bus? For
instance, gnome-settings-daemon takes a well-known name on the session
bus, but does various X11-centric things...
For completeness, here is what currently happens on "most" Linux
systems: one dbus-daemon --session per X11 login session, and possibly
another dbus-daemon in non-X11 login sessions if you explicitly start it.
:0 :1
----------- ------------ dbus-daemon --session
------------- /dev/tty1 -------------- X login session
-------------------------- getty login session
---------------- [1] dbus-daemon --session
========================================== XDG_RUNTIME_DIR
[1] only if explicitly started - no autolaunch
Regards,
S
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
