How do I "reset" a frozen/unresponding tty (mingetty)

utahnix · 01-30-2008, 02:05 PM

I have 3 servers attached to a cheap 4-port Belkin KVM switch. For some reason, when I am switching between computers, there are times when I lose my TTY on my Linux machine - it freezes and won't respond to keyboard input. I can switch to another TTY, but the TTY I had is lost. After a while, I lose all of my TTYs and have to initiate a reboot via SSH, or press Ctrl+Alt+Del.

When I go back to the "frozen" tty, I can still see everything (I don't get a blank screen)... I just can't type anything. It won't accept keyboard input of any kind.

Yes, it's a cheap switch, but I can't afford to get anything better at the moment. Money is tight.

What I've done is ps -A | grep tty and tried to kill -9 the processes attached to that tty, thinking that would do it. But it doesn't.

I don't have much experience with mingetty... is there a way for me to reset mingetty and bash on tty1 via tty2 or tty3?

This has been a nagging problem for several years, believe it or not, so any help would be very, very appreciated.

syg00 · 01-30-2008, 03:10 PM

Why not just kill the getty ???.
Hopefully should respawn, but if not just issue the command yourself.

utahnix · 01-30-2008, 08:46 PM

Quote:

Originally Posted by utahnix

What I've done is ps -A | grep tty and tried to kill -9 the processes attached to that tty, thinking that would do it. But it doesn't.

That is what I meant... I kill all the mingetty processes, but it doesn't do the trick.

DaRkBoDoM · 01-31-2008, 04:08 AM

Does the new mingetty process respawns after you killed the frozen one? Check this first

utahnix · 01-31-2008, 12:09 PM

Yes, it respawns, but that doesn't help. But I don't think bash is also respawning. Or does bash load when the user logs in?

DaRkBoDoM · 01-31-2008, 12:34 PM

Yes, bash loads when the user logs in.

I'm sorry, I can't help you more.

Baffo32 · 11-03-2008, 10:42 AM

I have had this problem occasionally for a long time when mistyping control codes in a tty and finally found the solution. A ^S (XOFF) sent to the terminal will halt -any- further transmission of data until a corresponding ^Q (XON) is recieved. Your keyboard switch is probably sending inadvertent ^S's. Typing Ctrl-Q in the frozen TTY may resolve the problem.

See 'Software flow control' in Wikipedia for more information. Seems I'm not allowed to post links on first post.

tek1024 · 12-13-2008, 01:13 AM

Oddly, I seem(ed) to be having this same problem exactly right now.

I logged into my box locally on tty1 and opened up a screen session. I stopped gdm (`/etc/init.d/gdm stop`) and one of my Xorg processes went through the roof with CPU usage. So, I killed the X process with SIGTERM as root, and immediately, the screen locked up.

I was able to log in through ssh and reconnect to my screen session; everything else remained running just like normal.

Finally, exactly 24 hours later, it occurred to me to run startx as root (`sudo -s`). $DISPLAY was set to :0.0 as normal. Success! My default X session started up and I was able to logout, which (since gdm wasn't running) sent me back to the console on tty7. Ctrl+Alt+F1 brought me back to tty1 and I was able to login successfully.

For clarity:

Problem: TTY is frozen / locked / hung and will not display.

Solution1: If root (UID 0) cannot login directly to SSH:

Code:

user@workingbox:~$ ssh user@frozenbox

#  SSH might ask for a password if you're not using
#+ public key authentication.

user@frozenbox:~$ sudo -s

#  See `man sudo` for details on the '-s' argument.
#  You will be prompted for your password if user isn't
#+ in your /etc/sudoers on "frozenbox".
#  See `man 5 sudoers` for more information.

root@frozenbox:~# ( [ -z $DISPLAY ] || [ "$DISPLAY" -ne $':0.0' ] ) && export DISPLAY=':0.0'

#  In English: if $DISPLAY isn't set OR it's not equal to ':0.0',
#+ export the value of $DISPLAY to be ':0.0' inside this shell.
#  For more, see <http://wooledge.org:8000/BashGuide>.

root@frozenbox:~# startx

#  This should start an X session on your local machine,
#+ allowing you to logout normally and type Ctrl+Alt+F1
#+ (or F2 through F6) to get back to a working console.

Solution2: Requires that `startx` can be executed by root && that ssh allows root to login directly:

Code:

user@workingbox:~$ ssh root@frozenbox '/usr/bin/startx -- localhost :0.0'

At least, FWIW, that solved my issues.

armandino · 02-25-2009, 03:22 AM

My problem is that the command

Code:

ps ax | grep tty

does not show any process associated to the frozen terminal and the command

Code:

ps ax | grep getty

does not show anything except the command line itself.
If I switch to the frozen terminal (ALT+Fx) I can see what follows:

Code:

#exit
logout
_

The cursor is NOT blinking.
The terminal seems to be just frozen in such a state, not responding to any input from the keyboard.
I'm sure there MUST be a simple command line which root can use to reset any terminal, but I haven't found it yet. Any help would be highly appreciated.

Of course I'd also like to know WHY an ordinary "exit" command produces such an effect, but that's another question...

frieza · 02-25-2009, 03:39 AM

are you using a VC?
must be if you are using mingetty...
try hitting scroll lock when the screen locks up like that

gsf · 04-01-2009, 10:14 AM

@frieza thanks! my tty just froze up and i came here via google. the kvm i use switches screens with a couple hits of the scroll lock, and i'm so used to it i didn't even think of that as a culprit, but, sure enough, hitting the scroll lock again on that tty thawed it right out.

.oOZe. · 12-03-2010, 05:45 PM

Quote:

Originally Posted by tek1024

Solution2: Requires that `startx` can be executed by root && that ssh allows root to login directly:

Code:

user@workingbox:~$ ssh root@frozenbox '/usr/bin/startx -- localhost :0.0'

At least, FWIW, that solved my issues.

Just wanted to thank you for posting this. Fixes an issue I am having since upgrading to FC14 with X freezing the console on exit: http://forums.fedoraforum.org/showth...=1#post1422831