On 05/03/13 21:03, Lennart Poettering wrote: > My general suggestion is that applications should generally die if their > display goes away (libX11 already enforces this...).
Right, but that only happens for GUI applications. One of the original rationales for D-Bus was that it was a way to avoid having stuff like gconfd still hanging around after the login session had finished (admittedly, logind's optional cgroup-killing makes that unnecessary, and is more thorough). > Having a "gnome-session.service" BTW sounds like a stop-gap though. My > intention is to move the service management bit of gnome-session into > systemd (or a generator for it), and then move the rest of it into > gnome-settings-daemon, and gnome-session would cease to exist What would "the program whose lifetime defines the GNOME session" be, in this world? At the moment things like gdm and startx work like this: register the new login session in PAM/logind/etc. run gnome-session (or startkde or ~/.xsession or whatever) wait for it to exit unregister the login session in PAM/logind/etc. clean up: put the greeter back up (gdm), terminate the X server (startx), or whatever >> 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. > > Not following here.. Not sure which bit you weren't following, so I'll try to reword both. The intended design (the one I prototyped) appears to be that logind runs systemd --user for the lifetime of the XDG_RUNTIME_DIR. If this lifetime includes any non-graphical login sessions (ssh, tty), then any session services that are a GUI are just not going to work: log in via ssh PAM registers a login session logind runs my systemd --user [--target default.target] default.target wants gnome-shell.desktop.service ... not going to work very well. >> 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. user-session-units contains a session service which starts Xorg. Under gdm, a $DISPLAY pointing to an existing Xorg instance is "passed in from outside" (and this is what the logind PAM module expects, in fact), so that session service is somewhere between useless and harmful. Similarly, running that service for a ssh login would be rather undesirable! >> 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'd suggest not to support this. In GNOME I would simply not allow > multiple local graphical logins of the same user. Instead, the user > should get a nice box that he is already logged in elsewhere. gdm currently limits to one login per user *per seat* - I can't "Switch User" (VT-switching) and log in a second time as myself, but if I had a USB display/keyboard widget providing a second "seat", I'd be able to log in on the "main screen" and on that at the same time. The idea is that each "seat" behaves like a separate computer in terms of input and output devices. Are you saying that you don't think it should be possible for a user to be logged-in on both seats? (Whenever there's more than one local X11 display, gdm itself certainly needs to be able to put a small GNOME session on behalf of the special-purpose 'gdm' user on each of them, in order to have the login screen present, with accessibility and stuff - but maybe it's OK to have a special case for system users.) S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel