Xorg+logind+DM issue: inactive graphical session for seat0
Laércio de Sousa
lbsousajr at gmail.com
Tue Oct 29 16:44:49 CET 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131029/703ce77a/attachment.html>
More information about the xorg-devel
mailing list