LinuxQuestions.org - How do I "reset" a frozen/unresponding tty (mingetty)

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - How do I "reset" a frozen/unresponding tty (mingetty) (https://www.linuxquestions.org/questions/linux-software-2/how-do-i-reset-a-frozen-unresponding-tty-mingetty-617462/)

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

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.

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

Quote:

Originally Posted by utahnix (Post 3040245)

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.

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

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?

Yes, bash loads when the user logs in.

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

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.

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

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

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

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

Quote:

Originally Posted by tek1024 (Post 3373870)

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