Hello,
I noticed a weird bug that is possibly caused by libpam-systemd.

Steps to reproduce (on a box with systemd as PID 1 process):

  0) login on TTY1 (virtual terminal 1) as a regular user

  1) start an X session with

     $ startx

  2) press [Ctrl+Alt+F2], in order to switch to TTY2

  3) login on TTY2 as the same user

  4) logout by pressing [Ctrl+D] on the empty command prompt

  5) awkwardly the screen goes automatically back to the X session
     (rather than showing a fresh new TTY2 login prompt)

  6) even more awkwardly, any keyboard and mouse input is ignored
     except for [Ctrl+Alt+F1], which however causes the screen to
     go blank and immediately enter sleep mode

  7) the only way out seems to be a poweroff command, issued by
     pressing the power button (which is handled by acpid)

I didn't try to SSH into the box and take a look at the system...


I suspect that this bug is caused by libpam-systemd, since starting
an X session on a box with systemd as PID 1 process, but without
libpam-systemd installed, causes the same inability to use X input
devices.

I noticed this bug some days ago with libpam-systemd/227-2: I waited
for version 228-2 to migrate to testing, before reporting the bug.
After reproducing the same exact misbehavior with libpam-systemd/228-2,
I decided that it is time to report it.

Could you please investigate this bug and fix it and/or forward it
upstream, as appropriate?

Thanks for your time!
Bye.

On Wed, 25 Nov 2015 22:20:05 +0100 Francesco Poli (wintermute) wrote:

[...]
[...]

I am adding the corresponding found version...

Am 11/25/2015 um 10:20 PM schrieb Francesco Poli (wintermute):

1..7

Tried those steps but I'm unable to reproduce it.

So I guess we will need at least a verbose journal log.
Which desktop environment is this? Does it make a difference if you use
a different window manager?

Hello Michael,
thanks for your kind reply.
It's unfortunate that you cannot reproduce the bug.
I'll try and see if I can provide more information...

Could you please specify the exact steps needed to obtain the log you
would like to see?

Fluxbox started with a custom ~/.xsession script.
The script basically executes the window manager with

  fluxbox & MANAGERPID=$!

then starts some other programs and then waits for Fluxbox to exit with

  wait $MANAGERPID

I can attach my ~/.xsession file, if you think it would be useful.

I'll try and find the time to install a different window manager /
desktop environment and test it, hopefully during the week-end...

Am 27.11.2015 um 00:16 schrieb Francesco Poli:

A Xorg.0.log and a journalctl -alb log might be helpful.

I don't think so.

To me this sounds like an X problem. Which Xorg version do you use?

[...]
They were taken just after reproducing the bug from a newly created SSH
session.
I hope these logs may help in understanding what's going on: I see some evdev errors in Xorg.0.log and a backtrace. Moreover I see some unclear (at least to me) messages from systemd-logind.

By the way, from within the SSH session I could close the X session by
just quitting Fluxbox with:

  $ killall -TERM fluxbox

After that, although my X session was gone, I could regain control of
the input devices (keyboard and mouse were back to normal) and I could
start a new X session from the console (TTY1).
In other words, a reboot was not strictly needed in order for the
system to come back to a normal working state.

[...]

It's possible, even though I cannot understand how X could be blamed
for the automatic switch back from TTY2 to TTY1 (which is occupied by
the X session).
On the other hand, it's more than plausible that the issue with ignored
input devices may be X's fault.

The one currently in Debian testing:

  $ dpkg -l | grep xserver-xorg-core | cut -c 1-60
  ii  xserver-xorg-core                       2:1.17.3-2

[...]

I installed xfce4 and tried to reproduce the bug.
I experienced the same exact misbehavior.

I think we can conclude that the bug does *not* depend on the window
manager / desktop environment...

Please tell me whether you need any further information in order to
investigate. Otherwise, please drop the moreinfo tag.

Thanks for your time!

Am 28.11.2015 um 19:23 schrieb Francesco Poli:

So far I don't know yet, how I can reproduce the problem. So I'll keep
the moreinfo tag.

I can reproduce the problem and experience almost the same behaviour as
Francesco. For me, it only happens when X is started on tty1 but Ctrl+D
on any other terminal takes you back to tty1. Usually the GUI is still
displayed but on occasion I have been returned to a screen with just a
portion of the Xorg log on it; the machine itself is still responsive
to X's mouse and keyboard after this.

My experience in step 7) in the first mail isn't quite the same. I get
a screen having a portion of the Xorg log with Ctrl+Alt+F1. The machine
is functional. Any other A-Z key presses end up on the login prompt of
tty2. gpm mouse also pastes to tty2. (Wouldn't this indicate actually
being on tty2 although an Xfce screen is the one visible)?

The machine is an up-to-date testing with Xfce. Using fvwm makes no
difference. Two logs are attached.

Regards,

Brian.

Isn't this the same (or a similar) issue:

https://bugs.freedesktop.org/show_bug.cgi?id=93164

[...]
similar to the one I experience, but his logs are more similar to your
logs (I get more error lines in my Xorg log).
You experience a different misbehavior, since your input devices are
not ignored by X (if I understand correctly).

Anyway, we are talking about three different X drivers (intel, radeon,
nouveau) with different features (for modesetting, and so forth):
hence, maybe the same bug has different symptoms.

I am more and more suspecting that this issue is ultimately caused by
systemd-logind / libpam-systemd...

I have installed Jessie without any tasks. The minimum for a working X
on this machine is xserver-xorg-video-nouveau. xserver-xorg-input-evdev,
xserver-xorg and xinit. libpam-systemd and dbus are not installed with
this arrangement,

The behaviour is similar to that on unstable when startx is on tty1 and
the user logs in and out of tty2, The one big difference is that X does
not shut down when the tty1 screen is displayed. Initially, the mouse and
keyboard function but CTRL+ALT+F1 results in them not working.

With libpam-systemd and dbus the behaviour is broadly similar.

The switching from one terminal to another only appears to occur when X
is on tty1. Occasionally it switches to tty1 and back to a login prompt
on tty2.

Regards,

Brian.

Upstream claims the problem is either X or the graphics driver:

https://github.com/systemd/systemd/issues/2061

(Not exactly the same reproducer, but similar).

On Tue, 1 Dec 2015 11:23:45 -0300 Felipe Sateler wrote:

[...]

Hello Felipe,
thanks for your comment.

However, the upstream bug report you pointed out does not seem to be
talking about the same issue. At least, to my systemd-newbie eyes...

Control: found -1 systemd/228-6
have you found a way to reproduce the bug?

I have just retried and I was able to reproduce the same exact
misbehavior as originally reported.
As I have previously stated, I was able to regain control of my box by
issuing the "killall -TERM fluxbox" command (I had scheduled such
command with at(1)). However, my X session was lost, unsurprisingly.

I also figured out an unpractical (yet effective) workaround: after
steps 0 through 3 (see my original bug report), instead of logging out
from the TTY2 shell, I followed the steps

  4') press [Ctrl+Alt+F1], in order to switch back to the X session

  5') from within a terminal emulator (such as xterm), figure out the
      PID of the shell running on TTY2 with

      $ ps aux | grep 'tty2.*-bash'

  6') call this PID "PID_OF_TTY2_SHELL"

  7') terminate that shell from within the X session terminal emulator
      with

      $ kill -TERM PID_OF_TTY2_SHELL

  8') go on doing anything you please with your X session


Needless to say, I would love to see this bug properly fixed, instead
of having to rely on unpractical workarounds...

I hope this can happen soon.

Thanks for your time!
Bye.

On Sat, 13 Feb 2016 22:02:02 +0100 Francesco Poli <invernomuto@paranoici.org> wrote:

Unfortunately I have not. Can you still reproduce the issue with v232?

Control: found -1 systemd/232-8
[...]

Yes, I have just reproduced the bug.
I lost control of my X session, then I regained control of my box
(since I had scheduled a "killall -TERM fluxbox" with at(1)).
The misbehavior seems to be identical to the one I experienced when I
originally reported the bug.

On Sat, 31 Dec 2016 16:10:13 +0100 Francesco Poli wrote:

[...]

Is there any progress on this issue?
Did you manage to reproduce it?
Have you pinpointed its cause?

I have just tested version 234-2.3 of systemd (currently in Debian
testing) and I again reproduced the issue.

Please let me know.
Thanks for your time!

Hello,

I am also experiencing the same problem and can consistently reproduce
it on both my laptop and desktop, which are both running Debian
Stretch.

I was able to reproduce a similar problem (x11 crashes instead of no
input) in a qemu virtual machine, but for some reason it's not
crashing anymore.

How can I disable using libpam-systemd? I tried installing
xserver-xorg-legacy, but it didn't change anything.

Best regards,
Matthew

Hello,

I found that this bug should be related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885318,
something is wrong with bash clear_console, you can test that by executing
clear_console in the tty
instead of exiting from logging out from it, and that should reproduce the
problem.

Best regards,
Hualet

Am 25.11.2015 um 22:20 schrieb Francesco Poli (wintermute):

As the original bug reporter, can you still reproduce the issue, and if
so, could you share your ~/.bash_logout file.

Thanks,
Michael

Control: found -1 systemd/237-4
thanks for following up on this bug report.

I have just reproduced the bug on an up-to-date Debian testing box,
with a slight difference.

Steps to reproduce are now (on a box with systemd as PID 1
process):

  0) login on TTY1 (virtual terminal 1) as a regular user

  1) start an X session with

     $ startx

  2) press [Ctrl+Alt+F2], in order to switch to TTY2

  3) login on TTY2 as the same user

  4) logout by pressing [Ctrl+D] on the empty command prompt

  5) awkwardly the screen goes automatically back to the X session
     (rather than showing a fresh new TTY2 login prompt)

  6) even more awkwardly, any keyboard and mouse input is ignored
     except for [Ctrl+Alt+F1], which however causes the X server
     to crash

  7) the screen shows the TTY1 bash with the latest error messages
     from the crashed X server and a prompt ready to accept new
     commands


My ~/.bash_logout is attached, but it's nothing special: it should be
identical to the one provided by the bash package in /etc/skel/

I am also attaching the Xorg.0.log produced by the crashed X server.

I hope this additional information will help to pinpoint the issue...

Bye.

Am 11.03.2018 um 19:12 schrieb Francesco Poli:

Can you comment out / remove the following three lines:

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi

and then test again, if you still encounter the problem.

I've just performed the test, after commenting out the three above
quoted lines.
The bug was not triggered.

It really seems that the bug is caused by some interaction with
clear_console ...

Am 12.03.2018 um 23:16 schrieb Francesco Poli:

Thanks for testing.

I'm going to reassing to bash and merge with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342

I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave
it up to the respective maintainers to reassign if necessary.

Regards,
Michael

Am 12.03.2018 um 23:45 schrieb Michael Biebl:

I will note, that clear_console is a debian specific addition to bash.

On Mon, 12 Mar 2018 23:45:44 +0100 Michael Biebl wrote:

[...]
[...]

Thanks to you for investigating and for asking me to perform the right
test!  ;-)

Good.

Looking forward to hearing from the bash Debian package maintainers
and/or from the X Strike Force...

Hi.

This bug seems the same as "fixed" bugs #805605 and #810660, which are
definitely not fixed yet.  The freeze is caused by vt switch performed by
'clear_console', and the commited "fix" just changed vt (choosed for switch)
from 1 and 2 to 5 and 6:

@@ -205,7 +205,7 @@
 #if defined(__linux__)
   num = vtstat.v_active;
 #endif
-  tmp_num = (num == 1 ? 2 : 1);
+  tmp_num = (num == 6 ? 5 : 6);

   /* switch vt to clear the scrollback buffer */
   if (ioctl(fd, VT_ACTIVATE, tmp_num))

So, since this can't fix anything, the bug is easily reproducible:

1. Start X on vt 6.
2. Log in at any other vt.
3. Run '/usr/bin/clear_console' and X crashes/freezes.