Control: retitle -1 xorg-server: Using startx w/o libpam-systemd, input does not work anymore
Hi! On Wed, 2016-02-10 at 18:42:39 +0100, Sven Joachim wrote: > On 2016-02-10 09:39 +0100, Guillem Jover wrote: > > > Source: xorg-server > > Source-Version: 2:1.18.1-1 > > Severity: important > > It would have been better to report the bug against the > xserver-xorg-core binary package, since that includes necessary > information from the bug script which is missing from your report. Sorry about that, I tend to avoid reportbug, so reporting against xserver-xorg-core would not have helped anyway. > > I just logged out and started X again, and no input was working any > > longer (builtin mouse and keyboard, nor hotplugged USB mouse). > > > > On this specific machine I'm using systemd, and I'm starting the X > > server using startx from a Linux console. I've also got the > > xserver-xorg-legacy package installed. This happens as well on another system using sysvinit. Both using the Intel KMS driver. > > I've bisected the packages and it seems this regression got introduced > > in 2:1.18.1-1, as 2:1.18.0-3 works perfectly fine. > > My hunch is that the fix[1] for upstream bug #92894[2] has triggered > this breakage. If I read the code in xorg-wrapper.c correctly, the > version from 1.18.0 would not actually drop root rights even if you have > a KMS driver for your video card(s). Now the KMS detection actually > works, and if you have a kernel graphics driver the wrapper drops root > rights meaning that you _must_ have a working systemd-logind to grant X > access to your input devices. > > Do you have libpam-systemd installed? Ah! I didn't have libpam-systemd installed on neither of the systems (sysvinit and systemd). I just had to restart these systems now anyway, and tried several things. I've now installed libpam-systemd on the system using systemd and things work as expected. For the one using sysvinit, instead I've added needs_root_rights=yes in /etc/X11/Xwrapper.config for now, as I don't want libpam-systemd on that one, this works fine too, and I'll switch to simply fixing the device permissions later on. I guess it would be nice to document this interaction/requirement more explicitly somewhere? Perhaps in the Xorg.wrap man page? But in any case the failing mode is pretty nasty, as the keyboard does not react anymore and you cannot ZAP the server or even switch to a virtual console to terminate it from there, at least the power button here sends ACPI events so the system can be shutdown cleanly. Ideally if root privs are to be dropped, logind is not available, and the input drivers will not have access to the input devices then the server could error out? But I'm not sure if that's architecturally sane. I guess the second best option would be, if logind is not present then the server perhaps should simply not drop root privs. And at least the server could print something on the Xorg.log. (But given that this is due to ignoring Recommends, I guess you might want to lower the severity.) Thanks, Guillem