Logging out of a tty returns to X and stops accepting input

crazy-yiuf · 12-27-2015, 05:24 PM

When I ctrl + alt + f3 (my f1 is X and my f2 is journald output) I can login just fine, but if I run logout, exit, or ctrl+d it goes back to X and doesn't accept any input, though the cursor is still blinking so it hasn't crashed. I assume that the correct behavior is to go back to the login prompt?

My ~/.bash_logout is just the default lines for clearing the screen. My inittab has the following lines:

Code:

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Does this sound like a quirk of the way I setup X? I installed Debian without an environment, updated to Sid, and then installed ratpoison, which pulled in X. That's about the extent of my tinkering with it.

This is not a super important issue; but it would be nice to fix, and I wanted to confirm the correct behavior just to be sure I don't crash someone else's server in the future. Thanks!

jpollard · 12-29-2015, 08:07 AM

the inittab isn't used in a systemd environment.

The "quirk" is not accepting more input in the X display. That shouldn't happen. On fedora, the getty keeps running, but that is specified by the "Restart=always" in the /usr/lib/systemd/system/getty@.service. Otherwise you get a black display with a blinking cursor on logout(is this what you mean?), or it goes back to the X display.

The tty login should occur whenever you switch to a console terminal (unless it is already logged in).

reference:
http://unix.stackexchange.com/questi...irtual-console

If you move the mouse in the X display does the cursor move?

crazy-yiuf · 12-29-2015, 04:07 PM

You're right, it works fine if I reboot and don't run startx. Once I have started X, exiting from tty3 returns to the X display and shows whatever was in the foreground, and no keyboard or mouse input is accepted, except for ctrl+alt+del which reboots. The "blinking cursor" I meant was in a terminal emulator in my X display.

Contents of /lib/systemd/system/getty@.service:

Code:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Getty on I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# On systems without virtual consoles, don't start any getty. Note
# that serial gettys are covered by serial-getty@.service, not this
# unit.
ConditionPathExists=/dev/tty0

[Service]
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes
#ExecStop=-/bin/chvt 2

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=

[Install]
WantedBy=getty.target
DefaultInstance=tty1

I added the ExecStop, which only runs on daemon-reload and not on exiting, like I expected it to. Commenting out the SendSIGHUP and TTYVhangup lines had no effect.

But thanks for your response, I'm learning a lot about systemd by fiddling with this. Maybe it's a bug in ratpoison? I might try another window manager eventually if no one has another idea.

crazy-yiuf · 12-29-2015, 04:40 PM

I noticed that if I press ctrl+alt+f1 from the frozen X display then startx crashes, drops back into tty1, and tells me

Code:

(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
(II) [KMS] Kernel modesetting enabled.
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) 
Fatal server error:
(EE) EnterVT failed for screen 0
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/home/yiuf/.local/share/xorg/Xorg.0.log" for additional information.
(EE) 
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 1007 requests (1007 known processed) with 0 events remaining.
xinit: connection to X server lost

waiting for X server to shut down

I should note that I always startx as a regular user. The log files it point to contain a subset of the stderr printed above.

jpollard · 12-29-2015, 08:01 PM

Which distribution are you using?

At one time, what startx does is grab the first unused console terminal, and switch to that. Going back to the console terminal you used startx on MIGHT cause an abort (it depends on what you do next), but the console terminal remains in a text mode. The console terminal used for the X display gets blanked when the X server terminates - and the terminal is marked idle again.

For the last couple of years, the X server uses the same console terminal that is tied to the process running startx... and an interrupt there would abort the X display. Certain types of aborts (-9 for instance) will leave the terminal in graphics mode, but no graphics being used - the X server didn't get to restore the terminal mode (thus a black screen with a cursor). A signal (1 - hangup/SIGHUP) directs the X server to terminate (which it did).

What is interesting about it is that it almost looks like the user startup for the X server isn't quite right.

Normally the X server should terminate when the last open connection closes --- The exit you show indicates 0 events
remaining, which makes me think everything was closed, but the server didn't terminate (I could be wrong on that, it has been over 10 years since I dug into the X server to see how it did things, and there has been a complete redesign done). The connection should be from the .xinitrc/.xsession (or whatever is being used by default). My .xinitrc has

Code:

#!/bin/sh

exec ck-launch-session mate-session

So the X server should terminate/be terminated by xinit when the "ck-launch-session" program terminates. startx is just a shell script wrapper around xinit to make getting required options setup properly/easier (xinit is tricky to use without startx). It is possible for the .xinitrc script to get hung waiting for something and have all the GUI
applications and/or window manager terminate (which again leaves the terminal with a blank display).

crazy-yiuf · 12-30-2015, 06:46 PM

I'm using Debian testing, though I think the bug has been around since well before Jessie became the new release. My .xinitrc contained:

Code:

#!/bin/sh
ratpoison

So I installed a different window manager (clfswm) and got it running, the same bug occurred. After it crashed, I tried startx -- :1 which also had the same behavior, so I guess we can rule out the window manager.

I did notice that the xorg log had a line or two more than the error, which I hadn't noticed before. I'll copy the last page or so for the sake of being more thorough, let me know if the earlier parts of the log could be useful.

Code:

[  6320.889] (II) systemd-logind: got resume for 13:64
[  6320.889] (II) systemd-logind: got resume for 226:0
[  6320.904] (II) AIGLX: Resuming AIGLX clients after VT switch
[  6320.906] (II) RADEON(0): EDID vendor "CMO", prod id 5543
[  6320.906] (II) RADEON(0): Printing DDC gathered Modelines:
[  6320.906] (II) RADEON(0): Modeline "1366x768"x0.0   69.30  1366 1382 1416 1466  768 770 776 788 -hsync -vsync (47.3 kHz eP)
[  6320.922] (II) systemd-logind: got resume for 13:79
[  6320.922] (--) synaptics: ETPS/2 Elantech Touchpad: touchpad found
[  6320.933] (II) systemd-logind: got resume for 13:71
[  6320.945] (II) systemd-logind: got resume for 13:68
[  6320.957] (II) systemd-logind: got resume for 13:67
[  6320.969] (II) systemd-logind: got resume for 13:78
[  6320.975] (II) systemd-logind: got pause for 13:76
[  6320.975] (II) systemd-logind: got pause for 13:65
[  6320.975] (II) systemd-logind: got pause for 13:72
[  6320.975] (II) systemd-logind: got pause for 13:69
[  6320.975] (II) systemd-logind: got pause for 13:66
[  6320.975] (II) systemd-logind: got pause for 13:64
[  6320.976] (II) systemd-logind: got pause for 226:0
[  6320.976] (II) systemd-logind: got pause for 13:79
[  6320.976] (II) systemd-logind: got pause for 13:71
[  6320.976] (II) systemd-logind: got pause for 13:68
[  6320.976] (II) systemd-logind: got pause for 13:67
[  6320.976] (II) systemd-logind: got pause for 13:78
[  6324.832] (II) AIGLX: Suspending AIGLX clients for VT switch
[  6324.832] (II) AIGLX: Resuming AIGLX clients after VT switch
[  6324.832] (EE) RADEON(0): failed to set mode: Permission denied(EE) 
Fatal server error:
[  6324.832] (EE) EnterVT failed for screen 0
[  6324.832] (EE) 
[  6324.832] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[  6324.832] (EE) Please also check the log file at "/home/yiuf/.local/share/xorg/Xorg.1.log" for additional information.
[  6324.833] (EE) 
[  6324.833] (II) AIGLX: Suspending AIGLX clients for VT switch
[  6324.997] (EE) Server terminated with error (1). Closing log file.