101

GNU Screen seems to freeze. Unable to enter user input.

I was using GNU screen and when I pressed the screen it became unresponsive. I can execute all the GNU screen commands, but can't enter user input. I don't want to kill this screen as I have important work and I don't want to lose it.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
sirus
  • 1,519
  • 2
  • 12
  • 17

5 Answers5

153

In the commands below, replace Ctrl with whatever your escape key is for screen commands.

Try Ctrl+a q, which is the sequence to unblock scrolling.

Ctrl+a s is the sequence that blocks scrolling, which makes screen seem like it freezes.

wkl
  • 77,184
  • 16
  • 165
  • 176
  • Well, it worked but only in one screen, in the other one it quit :( – sirus Dec 07 '10 at 00:45
  • 9
    You Sir, just made my day :) GNU screen documentation didn't come up when googling "gnu screen freeze" :/ – david_p Mar 12 '13 at 13:27
  • 1
    I had the same problem. Only one screen was frozen, which made me believe the problem was "screen-specific". Indeed, I had accidentally pressed Ctrl-A s. – smithfarm Mar 06 '14 at 10:10
  • I'm so used to using CTRL+A to go to the front of the command line to add ````sudo```` (since I forgot to start with it) that when I'm using screen, I lock it all the time! As previous comment says, ````CTRL+A q```` mostly works, sometimes exists the screen. Wish CTRL+A was not the default, on servers I use alot I change it to the "ESC" key. – johnnyB Jul 02 '14 at 21:08
  • 1
    Combine this nasty little beast with PuTTY's awful Ctrl+S which sends a XOFF and it really makes me fear the "s" on my keyboard. It's evil. Oddly the PuTTY keystroke is Ctrl+Q to send a XON... "q" is the savior. Thank you, 6 year old answer. – JNevill Aug 29 '16 at 15:17
  • In my case, it sometimes freezes without `Ctrl-A s` and `Ctrl-A q` doesn't help. Neither bash's own unlock. Closing my console and reopen the connection is the only thing I can do. – SenseException Oct 12 '17 at 08:14
  • I changed my command character to "Ctrl+o" with `escape ^Oo` in my .screenrc file – qneill Aug 31 '18 at 02:22
  • I am SO glad to have found this. I was using osm2pgsql to import a big osm.pbf file into the database and used `screen` to keep it running on an EC2 instance. The process was stuck at around 95% of the way, and it was no longer showing any progress, CPU 0%. After checking strace, it showed it was stuck on a `write(...)` syscall. I must have pressed the 'freeze scrollback` keys by mistake earlier. Now I try unfreezing and it worked again! So happy! – Mehdi Saffar Mar 13 '22 at 06:30
69

When using PuTTY, you can get an apparently freezed screen if you press Ctrl+s. This sends an Xoff signal blocking the terminal's output.

The solution is to press Ctrl+q to send the Xon signal.

Daniel Reis
  • 12,944
  • 6
  • 43
  • 71
10

The above works great if that is your issue.

This could also happen if you're ssh'd into another machine and haven't been to the window in awhile, then when you go back it's frozen. To fix this, you can try the following:

1) Create a new window

Ctrl-a c

2) ssh into the box where you ssh'd into the box in the window that's frozen.

3) Find the process the ssh is running under:

ps aux | grep <remote_box_on_frozen_screen>

or

ps aux | grep <your_user_id>

4) Kill the process

kill <process_id>
Hazok
  • 5,373
  • 4
  • 38
  • 48
  • Don't know how I got things into such an unresponsive state, since usually ctrl-q works for me, but I had to do this and lose my work. +1 for the break-here-in-case-of-emergency advice – taranaki May 03 '17 at 21:04
  • 2
    More often than not any frozen SSH connection can be forcefully closed by pressing `Enter`, then `~` and then `.` (see also [here](https://askubuntu.com/a/29952/130326)). – fotNelton Nov 02 '17 at 09:50
3

When you do screen -ls the first number of the screen name is the process id. So if the output is

There is a screen on:
    21605.pts-0.Random-server   (11/12/2017 11:44:15 PM)    (Detached)
1 Socket in /var/run/screen/S-kg.

Then this will kill it:

kill 21605

Notice the number for the kill command is the same as in the screen -ls output.

Pylinux
  • 11,278
  • 4
  • 60
  • 67
3

If you are using backtick commands in status line - that is, if your .screenrc has something like this:

backtick 1 0 60 /some/script.sh

then you want to be sure that the script is fast: apparently backtick execution blocks all IO to screen.

If you make changes to the config, you'll need to restart the screen session (as the config applies only to new sessions).

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
  • 1
    I had a backtick script running just fine for a very long time. Did a kernel update from 4.20.4 -> 5.4.80 and all of a sudden I faced this issue. For whatever reason my script which calls ```sensors -u``` is much slower with the new kernel... quite the rabbit hole this sent me down. – Chris Dec 03 '20 at 23:42