On Mon, Feb 18, 2013 at 12:13 PM, Simon McVittie <simon.mcvit...@collabora.co.uk> wrote: > 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.
right > 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. right - that's painfully obvious as we define the instance of the session based on the UID. >>> 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? :-) I have obviously not thought this all out... We may have to redefine systemd --user to start with a instance that defines a "user - seat" pair instead. That would leave multiple `systemd --user` pairs around, each serving the appropriate desktop. They could use a central DBus location if needed, share agents and such. Each would however run with DISPLAY hard set to the right display number, would that be an improvement? >> 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. this implies that services re-connect to the new display in case it changes, or better, services hangup when no longer in use in order to prevent to a nonexistant display. > 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). agreed, that would be ideal. >>> 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... ultimately this behavior will break, or it itself will have to be broken in two parts. Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
