It's a situation that has happened quite often to me: after I press (with a different intention) Ctrl-S in a terminal, the interaction (input or output) with it is frozen. It's probably a kind of "scroll lock" or whatever.

How do I unfreeze the terminal after this?

(This time, I have been working with apt-shell inside a bash inside urxvt--not sure which of them is responsible for the special handling of Ctrl-S: I was searching the history of commands backwards with C-r, as usual for readline, but then I wanted to go "back" forwards through the history with the usual--at least in Emacs--C-s (1, 2, 3), but that caused the terminal to freeze. Well, scrolling/paging to view past things still works in the terminal, but no interaction with the processes run there.)

imz -- Ivan Zakharyaschev
  • 14,533
  • 12
  • 58
  • 118
  • 42
    I was working in `vim` and I pressed Ctrl-S to save my edits. Uh-oh `XD` – ADTC Jul 22 '16 at 14:47
  • 16
    Why does that exist in first place? – neverMind9 Dec 13 '18 at 23:31
  • I was so glad to find this. I hit it so often when using `CTRL+A` to jump to the start of a line. `CTRL+C` and `Return` was working for me, but I will use the answer below in future. – user7543 Sep 07 '20 at 10:17
  • 2
    This sometimes happens to me: accidentally freezing `Vim`, in a xfce4-terminal (it's actually the terminal that is frozen). Various `xon-xoff` solutions (`Ctrl-Q` ...) had no effect. Although no keyboard shortcut was evident, I noticed that from the terminal menu that the terminal had become set to "Read-Only." Unchecking that restored terminal responsiveness. – Victoria Stuart Sep 29 '20 at 21:33
  • Just in case the terminal froze after ssh lost connection: tilde - period, see https://unix.stackexchange.com/a/196724/296434 . Cross linking because that post is harder to find when just googling on `terminal freeze` – Roland Oct 08 '20 at 22:58
  • 2
    Thank you @VictoriaStuart - this has been driving me insane. Now I just need to figure out the keystroke that causes the RO mode... – csknk Jun 22 '21 at 13:45
  • `Enter ↵`, `~`, `.` is what I needed: https://stackoverflow.com/a/43189095/470749 – Ryan Jul 20 '21 at 16:00
  • 1
    @Ryan that's to break SSH sesion. – imz -- Ivan Zakharyaschev Jul 20 '21 at 17:16
  • As mentioned below, put `stty -ixon` in your shell startup script to disable. zsh also has an option you can use instead: `unsetopt FLOW_CONTROL`. – Big McLargeHuge Jul 19 '22 at 18:30

3 Answers3


Press Ctrl-Q to unfreeze.

This stop/start scheme is software flow control, which is implemented by the OS's terminal device driver rather than the shell or terminal emulator. It can be configured with the stty command.

To disable it altogether, put stty -ixon in a shell startup script such as ~/.bashrc or ~/.zshrc. To instead just allow any key to get things flowing again, use stty ixany.

  • 11,933
  • 1
  • 17
  • 12
  • 10
    Thank you! BTW, [there](http://unix.stackexchange.com/questions/232/unix-linux-pranks/297#297) they suggested `Ctrl-C`; does it work, too? (And at [another place](http://unix.stackexchange.com/questions/6890/what-is-making-my-cursor-randomly-disappear-when-using-gnome-teminal/6896#6896), they suggested `Ctrl-Q`, just as you.) – imz -- Ivan Zakharyaschev Apr 27 '11 at 12:41
  • Yes, both `Ctrl-C` and `Ctrl-Q` work (at least, for me). – imz -- Ivan Zakharyaschev Apr 27 '11 at 12:44
  • 29
    Ctrl-C does work, but it also sends an interrupt signal, which one generally wouldn't want. (Btw, the keys being used for these things are all configurable through `stty`.) – ak2 Apr 27 '11 at 13:10
  • 1
    Wow, I am so happy to stumble upon this. tabs would freeze a lot for me in urxvt. I guess because I hit ctrl+s by mistake. I use ctrl+a,ctrl+e,and ctrl+o a lot. Thanks! – matchew Apr 09 '13 at 15:40
  • 2
    I remember trying out this combination on my Apple ][ clone, and it worked there too - `Ctrl-S` and then `Ctrl-Q` to resume. – sashoalm Jan 16 '14 at 08:44
  • Is Ctrl-A a working solution?.. http://unix.stackexchange.com/a/147617/4319 It's Home. – imz -- Ivan Zakharyaschev Jul 31 '14 at 09:05
  • 2
    Interestingly, when an Emacs is running in the terminal, C-s doesn't freeze it. So, this means that Emacs changes this driver setting and then restores it on exit (or lets it be restored somehow automatically). So sometimes this setting seems to be under an intentional control of a program running in the terminal (which could be the shell or Emacs). – imz -- Ivan Zakharyaschev Aug 04 '14 at 12:18
  • 24
    THANK GOD !! This has been something bugging me for years. Not sure why VIM just hasn't implemented this as a native shortcut for save instead of whatever the hell it does. Good to know there is an escape from the prison which is the frozen VIM screen due to natural use of CTRL+S (save shortcut) that is applicable in nearly all applications EXCEPT VIM. – Kraang Prime Mar 14 '15 at 18:20
  • 13
    @SanuelJackson Ctrl-S "save shortcut" is applicable in nearly all DESKTOP application EXCEPT vim. And Except Emacs. And Nano. And every other "application" you can run on a terminal, exactly because it's already used by the terminal for flow control. It's the same reason you won't find a Linux Desktop application using the Ctrl-Alt-FN shortcuts: because they're already used by the system. – gerlos Sep 23 '15 at 15:45
  • 2
    @SamuelJackson `:w` is much powerer than a C-s shortcut. You can use it to save to a different command, to pipe the buffer's contents to a program or to write to a different file - all of which can't happen with just a shortcut. – Al.G. Sep 04 '16 at 09:24
  • 5
    @SamuelJackson there is nothing stopping you from binding ctrl-s to :w command in your .vimrc, see here for example: http://stackoverflow.com/a/11298171/2380702 – xor Sep 22 '16 at 10:03
  • On ubuntu 16.04, running stty -ixon disable the freeze effect of ctrl-s, and replaces it with something like "i-search", another feature I don't need at all. As I use emacs shortcuts a lot at my prompt and also switch keyboards up often, I end up hitting ctrl-s by mistake many times a day. Is there any way to let it do nothing at all? (using gnome-terminal btw) – rien333 Nov 07 '16 at 14:04
  • @ak2 Wow.. you solved a childhood problem.. Bu why does ctrl-S only freezes in cmd line mode and not in GUI mode? – Shashank Vyas Dec 22 '16 at 16:54
  • For MSYS2 use `Ctrl-Z`. Neither `Ctrl-C` or `Ctrl-Q` work – roblogic Jun 08 '17 at 04:25
  • Be aware that `reset` command will also enable flow control, so you'll need to issue `stty -ixon` again. – Nash Bridges Oct 23 '17 at 08:20
  • If you put this in your `.profile`, it causes a popup error to appear on login hat reads: "inappropriate ioctl for device" in Ubuntu 17.10: https://askubuntu.com/questions/918169/error-found-while-loading-home-username-profile/970634#970634 – Ciro Santilli OurBigBook.com Oct 29 '17 at 17:34
  • @KraangPrime I remember starting off using Nano/pico — even worse: `CTRL+X y` – Stan Strum Jan 19 '18 at 17:58
  • What sort of startup script, for the shell, e.g. `~/.bashrc`? – Nick T Apr 05 '18 at 15:38
  • Note that when you are searching command with `CTRL-R`, the side effect of `stty -ixon` is that you can also do revert search using the mentioned `CTRL-S`, which is very handy, if you keep pushing `CTRL-R` too fast :) – jirislav May 12 '18 at 22:58
  • 1
    I added `stty -ixon` to `~/.bashrc`, then restarted emacs daemon, tmux sessions (a true logout login cycle), then it worked – Thamme Gowda Aug 30 '18 at 19:21
  • Using Emacs through GNU Screen might also disable ctrl-s and ctrl-x-s for search and save-file, which of course is very annoying when it happens. I can keep Emacs sessions for weeks and months otherwise. To make Emacs see ctrl-s again I found `ctrl-a` `f` which toogles the current GNU-Screen "window" between three states: `-flow(auto)`, `-flow` and `+flow` where `+flow` shouldn't be used. (Ctrl-a is the default GNU Screen key, could be different on other setups) – Kjetil S. Jul 19 '19 at 08:26
  • @gerlos The reason Ctrl S works fine in every desktop application and causes such a mess on Linux (possibly other Unixes) is because of people like you who defend algorithms used 40 years ago when modern computers were invented and output was on a paper instead of a screen. Ctrl S/Q should have been removed 30 years ago and it's a shame such code still dwells in the heart of every linux server. – John Sep 01 '19 at 01:58
  • 3
    @John sorry, I wasn't "defending" anything, just pointing out that exist different ecosystems (terminals, desktops, etc) with different interaction patterns. These ecosystems work they way they work for both historical and practical reasons that are still valid today. I understand that it can be annoying if you're not used to it. But thinking that there should be just one way of doing anything regardless of the context is plainly wrong. – gerlos Sep 05 '19 at 21:52
  • 1
    @gerlos Which partical reason would you provide for this 'feature' to be part of the linux kernel and exposed to tens of millions of users every day ? historic reasons are not a reason to keep a horrible 'feature' alive, they are reason to remove. – John Sep 06 '19 at 02:27
  • 3
    @John You use Ctrl-s (and Ctrl-Q) to pause (and resume) long output scrolling on terminals so you can read what's going on. That's it. It's true, you can use pagers like less or more, but only if you expect a long output coming in, if terminals support them, and if the system can run them (it might not be possible in some emergency situations). Moreover, some (hw and sw) terminals doesn't even support scrolling, so you can't scroll bak to read (serial consoles are often used on embedded devices). So please stop complaining about something you never used and don't understand. – gerlos Sep 06 '19 at 09:08

Ctrl-Q is indeed the answer. I thought I'd toss in a little history of this that is too long to fit in the margins of ak2's correct answer.

Back in the dark ages, a terminal was a large piece of equipment that connected to a remote device (originally another terminal because teletypes were so much easier to learn to operate than a telegraph key) over a long wire or via phone lines with modems. By the time Unix was developing, the ASCII code was already well established (although the competing EBCDIC code from IBM was still a force to be reckoned with).

The earliest terminals kept a printed record of every character received. As long as the characters arrived no faster than the print head could type them, at least. But as soon as CRT based terminals were possible, the problem arose that only about 25 lines fit on the CRT, and 25 lines of 80 characters represented enough RAM that no one thought seriously about providing more RAM for characters that had scrolled off the top of the screen.

So some convention was needed to signal that the sending end should pause to let the reader catch up.

The 7-bit ASCII code has 33 code points devoted to control characters (0 to 31 and 127). Some of those had really well established purposes, such as NUL (blank paper tape leader for threading, gaps, and splices), DEL ("crossed out" characters on paper tape indicated by punching all seven holes), BEL (ding!), CR, LF, and TAB. But four were defined explicitly for controlling the terminal device itself (DC1 to DC4 aka Ctrl+Q, Ctrl+R, Ctrl+S and Ctrl+T).

My best guess is that some engineer thought that (as mnemonics go), "S" for "Stop" and "Q" for "Continue" weren't too bad, and assigned DC3 to mean "please stop sending" and DC1 to mean "ok, continue sending now".

Even that convention was already well established by the time Unix was leaving nest at Bell Labs to go out into the world.

The convention is known as software flow control, and is extremely common in real serial devices. It is not easy to implement correctly, as it prevents the use of either of those characters for any other purpose in the communications channel, and the Stop signal has to be handled ahead of any pending received characters to avoid sending more than the receiving end can handle.

If practical, using additional signals out of band from the serial data stream for flow control is vastly preferred. On directly wired connections that can afford the additional signal wires, you will find hardware handshake in use, which frees up those characters for other uses.

Of course, today's terminal window is not using an actual physical serial port, has scroll bars, and doesn't really need software handshaking at all. But the convention persists.

I recall the claim that Richard Stallman received complaints about his mapping Ctrl+S to incremental-search in the first releases of emacs, and that he was rather unsympathetic to any user that had to depend on a 7-bit, software flow controlled connection.

  • 4,791
  • 1
  • 12
  • 6
  • 2
    Thanke.. very interesting... I've been wondering: Why on earth would anyone choose to *Continue* a process with "Q" which is commonly used (now) for Quit... The QRST grouping explains it ..... – Peter.O Apr 27 '11 at 22:40
  • This one took me a long time to figure out too, but after I found Q, I was like "Man their so close on the keyboard how did I not hit it before!!!" – RandomNickName42 Apr 27 '11 at 22:43
  • 16
    Thanks very much for that bit of history. I recently disabled flow control by default in a terminal emulator I maintain, but had to reinstate it rather quickly after vocal protests from Unix traditionalists who do still use it. I set the ixany bit instead, so at least people who press ^S without knowing about ^Q don't get stuck. – ak2 Apr 27 '11 at 22:45
  • 3
    @RBerteig I ran into something similar learning about backspace and delete. Backspace is officially ^H and delete is ^? Some people like the Emacs developers (Stallman again?) wanted ^H available for general purpose like shortcuts like Help. The escape sequence ^[[3~ or something like that was created to replace ^? and backspace now became the old delete character ^?. In fact, I've seen ncurses specifically patched on Linux distros to remap thoses keys in terminfo whereas ncurses on FreeBSD is unpatched causing some of the annoying confusion causing backspace to not work. – penguin359 Apr 28 '11 at 10:48
  • @penguin359 - Actually, I believe you're talking about the VT control codes which began with [[ (sometimes called ANSI codes which were often used for color and other purposes). VT52 and VT100 are among the most common versions of that. – Erik Funkenbusch Apr 28 '11 at 11:41
  • 33
    I used to wonder why DEL had the code 127 rather than being grouped with the other control characters, until I first played with some paper tape and an ASR33. Once I realized that it had the effect of punching all the holes, which meant it could be overstruck on any previously punched character to delete it, it made sense. – RBerteig Apr 28 '11 at 19:08
  • 1
    @Mystere Your right, it's not an ANSI Escape sequence, but an [ANSI Control Sequence](http://www.inwap.com/pdp10/ansicode.txt). Escape \(^\[) followed by [ is an Escape sequence that represents the CSI ANSI Control charater. CSI starts an ANSI Control sequence. The [DEC Terminals](http://vt100.net/docs/vt220-rm/chapter3.html) as far as I can tell never used ^[[3~ for Delete, I think that was added in XTerm. – penguin359 Apr 28 '11 at 20:40
  • 1
    @penguin359 The VT220 sends `^[[3~` for the Remove key that's part of the six-key editing keypad. Seems to make plenty of sense to equate that with the 'Delete' key on PC keyboards. See also http://www.quadibloc.com/comp/images/vt220.gif for a picture. – ak2 Apr 29 '11 at 06:21
  • @ak2 Looks like you might be [right](http://www.connectrf.com/documents/vt220.html). Odd, I can't find mention of the remove and similar function keys on the [VT-200 Programmer Reference Manual](http://vt100.net/docs/vt220-rm/) from [vt100.net](http://vt100.net/). Must just be incomplete. I'd love to get my hands on a real DEC Terminal someday. – penguin359 Apr 29 '11 at 07:47
  • 1
    @penguin359 The editing keypad appears on the page you linked to actually, with a pointer to [a table](http://vt100.net/docs/vt220-rm/table3-1.html) listing its keys. – ak2 Apr 29 '11 at 08:57
  • @ak2 you're right, I guess I was taking too quick a glance. I didn't understand what – penguin359 Apr 29 '11 at 10:54
  • Interesting article on History, however since then, VIM has undergone many re-writes, none of which take into account modern computing shortcuts. This would be fantastic if working with text in the early 80's however I do believe we have moved on, and it's time for VIM (including windows compile) to move forward as well. Please send the memo as I believe the core dev's are stuck in a time-loop back in the 80's somewhere. – Kraang Prime Mar 14 '15 at 18:24
  • I got an IBM 3161 ASCII terminal a while back - this answer helped me make sense of it... It's working now! Thanks. Any idea why terminal emulators even bother with the DC1 and DC3 instructions though? – Wyatt Ward Aug 09 '15 at 00:28
  • 4
    @SanuelJackson It's been some time since I looked closely, but the default vimrc that ships with windows has mapped to ":update" for many years. I'm also fairly certain I've seen it on some distros for gvim in the past as well. If you are using vim in a terminal, though, this history is still very much relevant. Modern terminal emulators still implement the flow control keys, so even if vim mapped them it would never see them unless each user went out of their way to disable flow control as described in the accepted answer. – Drew Apr 22 '16 at 22:30
  • This means that `^Q` and `^S` doesn't correspond to SIGCONT and SIGSTOP right? – CMCDragonkai Jan 11 '17 at 08:20
  • 5
    @CMCDragonkai Nope. Nothing at all to do with `SIGCONT` and `SIGSTOP`. `SIGTSTP` is generated by the terminal driver when `^Z` is typed, and can be ignored unlike `SIGSTOP` which cannot. No keystroke sends `SIGCONT`, it is the signal sent by whatever command in your shell you use to continue a stopped job. The `^S` and `^Q` keys act directly on the terminal driver stack, and don't generally send a signal. – RBerteig Jan 24 '17 at 20:09
  • 1
    I don't know when video display terminals first became practical, but I would expect that DC3/DC1 flow control predates them. An ASR-33 may never need to autonomously request that a remote paper tape reader stop and restart, but an operator who needs to swap out a roll of paper for the printer or punch might recognize such a need. Someone who was using a video terminal to inspect a paper tape might need to start or stop the reader, but that could be done with a button on the reader. I would not expect people to frequently start and stop remote tapes to give themselves time to read stuff. – supercat May 22 '17 at 05:48
  • If someone needs to forward a news story to many other people, any time the reader spends waiting for someone is time it can't be sending to anyone else. Better to have the recipient capture the story to paper tape or print paper, and then peruse it at leisure. – supercat May 22 '17 at 05:50

Control Keys: perfrom special functions on Shell

  • Ctrl-S : Pause Display
  • Ctrl-Q : Restart Display
  • Ctrl-C : Cancel Operation
  • Ctrl-U : Cancel Line
  • Ctrl-D : Signal End of File
  • 2,222
  • 2
  • 21
  • 25