Re: [systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0
Hi On Tue, Oct 29, 2013 at 4:44 PM, Laércio de Sousa lbsous...@gmail.com wrote: I would append another approach to the list: * For non-seat0 seats, X server should open no VT at all. Currently, even with -sharevts option, it seems Xorg does open a VT, although it can't control this. Yes, please! We shouldn't touch VTs at all if we're not on seat0. I never understood why we have -sharedvt.. It doesn't make any sense. Furthermore, if we remove -sharedvt we could also run the xserver with CONFIG_VT=n. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0
Hello there! I'm posting this question in both systemd-devel and xorg-devel lists because I want to know each one's opinion about it. In some multiseat setups involving multiple video cards, sometimes we get the following error: depending on the display manager currently used, systemd-logind gives us an INACTIVE graphical session for seat0. An interesting analysis of the problem can be found at https://bugzilla.redhat.com/show_bug.cgi?id=1018196. To summarize, due to some race condition between seat0 and non-seat0 seats, a non-seat0 X server can steal the VT expected by seat0 X server. In this case, unless XDG_VTNR is explicitly defined by display manager, the pam_systemd module fails to infer the correct VT for seat0 X server (i.e., the one corresponding to vtXX command line argument), returning XDG_VTNR=0 to seat0's graphic session, which causes all the trouble. Joseph Nuzman, who opened the bug above, suggests some approachs to avoid this problem, and I really want to know what do you think about them: * DMs should always set the XDG_VTNR variable for seat0. GDM currently doesn't set this variable, but a forked version of LightDM, maintained by Ubuntu Multiseat team (merging into upstream is under consideration), does it. * pam_systemd should have its heuristic to infer the seat0 VT number improved. Maybe parsing X server /proc/pid/cmdline for a vtXX argument. * DMs should ensure that seat0 X server starts before any other one. Stefan Brüns has provided a similar approach for KDM on Fedora/openSUSE: it ensures seat0 X server starts at the same VT previously used by Plymouth. I would append another approach to the list: * For non-seat0 seats, X server should open no VT at all. Currently, even with -sharevts option, it seems Xorg does open a VT, although it can't control this. CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0
On Tue, Oct 29, 2013 at 01:44:49PM -0200, Laércio de Sousa wrote: Joseph Nuzman, who opened the bug above, suggests some approachs to avoid this problem, and I really want to know what do you think about them: * DMs should always set the XDG_VTNR variable for seat0. GDM currently doesn't set this variable, but a forked version of LightDM, maintained by Ubuntu Multiseat team (merging into upstream is under consideration), does it. If I understand the analysis, *two* different X instances would share the same VT. This might work, but option 4 seems superior. * pam_systemd should have its heuristic to infer the seat0 VT number improved. Maybe parsing X server /proc/pid/cmdline for a vtXX argument. This looks ugly. * DMs should ensure that seat0 X server starts before any other one. Stefan Brüns has provided a similar approach for KDM on Fedora/openSUSE: it ensures seat0 X server starts at the same VT previously used by Plymouth. This looks racy — let's say that at some point two users on two seats kill their X's. It's impossible to order such events. I would append another approach to the list: * For non-seat0 seats, X server should open no VT at all. Currently, even with -sharevts option, it seems Xorg does open a VT, although it can't control this. Right, so why not do this? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
