On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie <[email protected]> wrote: > I've recently been researching systemd's current support for user > sessions, with the goal of sorting out any remaining omissions/issues > and having GDM integrate well with it. > > It looks as though the intention is that if I have overlapping sessions > like this: > > * 14:00: log in to GDM on X11 display :0 > * 14:10: log in via ssh or getty or something > * 14:20: log out from :0 > * 14:30: log in to GDM on X11 display :1 > * 14:40: log out from ssh/getty > * 14:50: log out from :1 > > then from 14:00 to 14:50 I have one XDG_RUNTIME_DIR, one 'systemd > --user' instance (as per systemd's TODO: started by logind using > [email protected], on behalf of pam_systemd) and one 'dbus-daemon --session' > instance (presumably started by that 'systemd --user'). Is that how it's > meant to work? Or am I meant to have one 'systemd --user' instance per > login session, or one D-Bus session bus per login session?
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. For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. > Is there any plan for how GUI processes started via session D-Bus > activation should pick up the right value for $DISPLAY (in my example: > ":0" until 14:20, nothing from 14:20 to 14:30, ":1" from 14:30 onwards) > and $XAUTHORITY, or is that something that still needs to be solved? Or > are GUI processes meant to obtain their X11 display and authority file > in some other way? GUI processes running under a gnome-session@:0.service should be able to getenv(DISPLAY) if it's set by [email protected] (Environment=DISPLAY=%I). but yeah, no answer for dbus activated services. > One simple example of a GUI process started by session D-Bus activation > is that /usr/bin/gnome-terminal is just a "remote control" which > activates ${libexecdir}/gnome-terminal-server, a GUI application, and > tells it to open a new window. This is currently a D-Bus session service > using traditional D-Bus activation, but it should presumably become a > systemd user service, with the dbus-daemon handing off activation to the > user instance of systemd. > > If used in my example above, a gnome-terminal-server started at 14:05 > ought to use display :0, and exit at 14:20 when it loses its connection > to the X11 server; if I then run gnome-terminal at (say) 14:35, the > desired result is a new gnome-terminal-server on display :1. If the > overlapping sessions share a 'systemd --user' and a 'dbus-daemon > --session', then that would even work if I ran gnome-terminal from the > text-mode session, which is a nice improvement over how it currently > works with a session-scoped dbus-daemon (it'd fail because the text-mode > session either doesn't have a dbus-daemon, or has a dbus-daemon with no > $DISPLAY). > > 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? > I don't know much about Wayland, but it appears that it normally has one > socket "wayland-0" in the XDG_RUNTIME_DIR, and only needs to use further > environment variables if there's more than one Wayland compositor > sharing an XDG_RUNTIME_DIR. this also seems like it would need to become instanced - [email protected]... I looked into wayland earlier and it wasn't ready for user session integration though - too much stuff in weston currently breaks right through the user-system separation for it to be ready for user-sessions. Auke _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
