Logging out of a tty returns to X and stops accepting input
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Logging out of a tty returns to X and stops accepting input
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:
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!
Last edited by crazy-yiuf; 12-27-2015 at 05:26 PM.
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).
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.
Last edited by crazy-yiuf; 12-29-2015 at 04:15 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.
Last edited by crazy-yiuf; 12-29-2015 at 05:49 PM.
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.