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!

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?

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: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.

I noticed that if I press ctrl+alt+f1 from the frozen X display then startx crashes, drops back into tty1, and tells me
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.

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
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:

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.