Bug#867745: libpam-systemd: log out from a TTY and your X input devices get lost!
On 07/09/2017 10:22 AM, Brian Potkin wrote: fvwm here. But I do not think the WM is relevant. me either, but since three wm reported now, it is more evidence that wm isn't relevant. I reverted back to sysvinit/uninstalled systemd (and configured Xwrapper to run X as root again, so it would start without the systemd bits). With systemd gone, the problem no longer occurs. A simple change to PID 1 as init makes no difference to the behaviour here. Altering ~/,bash_logout gives a quick fix (workaround?). I don't think it is the pid 1 part of the systemd package that causes this issue, but rather logind since that is involved with VTs, and logind is invoked when the issue occurs (and logind is removed when uninstalling systemd and the issue is resolved); logind is part of the main systemd package, so IMO systemd is the correct package to report the bug against. After rebooting with sysvinit-core installed, you have to apt-get remove systemd to fix the behavior, or the systemd bits are still there. And, when you do uninstall systemd, you will break X because stretch is setup to rely on some systemd bits (?maybe consolekit?) to not need to start X as root. You will need to add the line: needs_root_rights=yes to /etc/X11/Xwrapper.config to get X to start again without the systemd bits. I suppose it could be coincidence, and the bug lies elsewhere and some systemd component just causes the bug to manifest. But, so far I have seen/ been bitten by *a lot* of buggy behavior in systemd, so biased toward suspecting this is yet another systemd bug.
Bug#867745: libpam-systemd: log out from a TTY and your X input devices get lost!
On Sun 09 Jul 2017 at 00:37:08 -0700, Grant Chesy wrote: > Followup-For: Bug #806256 > Package: systemd > Version: 232-25 > > Hello, I also experienced this bug. > > steps to reproduce: > 1. start X with startx > 2. switch to any VT from X > 3. log in as the same user* as the user running X > 4. logout from VT. If login to the VT was as the same user as the user > running X, the VT closed and I was automatically switched back to X without > input working. Yep. I'll draw attention to #791342 and #858073. They are likely filed against the wrong package. > *If the login to the VT was as root, the problem did not occur. Upon > logout, the VT just displayed a new login prompt, as expected, and I was > able to switch back to the functioning X session logged in as my regular > user. > > Reproducible=always. I've just spent some time re-testing. Reproducible on up-to-date stretch and sid distributions. > In my case, no keypresses would work after returning to X except magic > sysreq. But, X was still updating the display. xorg cpu utilization went > to 120% while in this broken state (dual core 8yr old netbook). CTRL+ALT+F1 closes X for me and returns things to normal. > Since you asked the original submitter about window manager, I am running > e17. fvwm here. But I do not think the WM is relevant. > I reverted back to sysvinit/uninstalled systemd (and configured Xwrapper to > run X as root again, so it would start without the systemd bits). With > systemd gone, the problem no longer occurs. A simple change to PID 1 as init makes no difference to the behaviour here. Altering ~/,bash_logout gives a quick fix (workaround?). -- Brian.
Bug#867745: libpam-systemd: log out from a TTY and your X input devices get lost!
Followup-For: Bug #806256 Package: systemd Version: 232-25 Hello, I also experienced this bug. steps to reproduce: 1. start X with startx 2. switch to any VT from X 3. log in as the same user* as the user running X 4. logout from VT. If login to the VT was as the same user as the user running X, the VT closed and I was automatically switched back to X without input working. *If the login to the VT was as root, the problem did not occur. Upon logout, the VT just displayed a new login prompt, as expected, and I was able to switch back to the functioning X session logged in as my regular user. Reproducible=always. In my case, no keypresses would work after returning to X except magic sysreq. But, X was still updating the display. xorg cpu utilization went to 120% while in this broken state (dual core 8yr old netbook). Since you asked the original submitter about window manager, I am running e17. I reverted back to sysvinit/uninstalled systemd (and configured Xwrapper to run X as root again, so it would start without the systemd bits). With systemd gone, the problem no longer occurs.
