Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I often start to read a huge file and then want to quit after a while, but there is a lag from pressing
Ctrl+C to the program stops. Is there a chance of shortening the lag by pressing the Ctrl+C key several times? Or am I wasting my keypresses?

share|improve this question
I have noticed when running a process that calls various child processes, Ctrl-C will sometimes interrupt the running child, but not the parent process. That is true in bash, but not the case in zsh which always closes the parent. It is one of the reasons I like zsh. – joeytwiddle Jan 15 '14 at 15:27
Yes, just like pressing the elevator button or the cross-walk button repeatedly will cause the elevator to come sooner or the light to turn green quicker. – Michael Jan 15 '14 at 15:40
Yes just like elevator and crosswalk buttons, CTRL-C can also get sticky or rusty or develop iffy connections. Pressing more times is a good tactic because only one press has to register for the elevator to come, the walk sign to light up, or the program to close. – hippietrail Jan 15 '14 at 17:40
@hippietrail but your shell will print out ^C when it registers the press (at least bash does) – WChargin Jan 15 '14 at 23:05
For what it's worth, I don't consider it wasting my keypresses -- I consider it venting some frustration in a non-damaging way. (I usually hit it 2-3 times, but that's partially because I "grew up on" terminals attached over phone lines where you couldn't always count on every single keystroke reaching the machine.) – keshlam Jan 16 '14 at 3:16

6 Answers 6

up vote 36 down vote accepted

After the first Ctrl-C, the program will receive SIGINT and usually starts cleaning up (deleting tmp files, closing sockets, etc.). If you hit Ctrl-C again while that is going on, it may happen that you interrupt the clean up routine (i.e. the additional signal might be acted upon instead of being left alone), leaving a mess behind. While this usually is not the case, more commonly the additional signals are in fact sent after the process finished (because of the inherent delays in the interaction of the operator with the system). That means that signals are received by another process (often shell, but not always). If that recipient doesn't handle this signal properly (like shell usually does - see Jenny D's answer) you may be unpleasantly surprised by the outcome of such an action.

share|improve this answer
Why should it interrupt the clean up routine? It's just another signal INT that the process recieves. – chaos Jan 15 '14 at 8:18
@chaos makes more sense now? – peterph Jan 15 '14 at 8:40
@chaos Why should it? It should if the clean up routine has gotten hung up and you want to stop it. Does it actually work this way? Yes, quite often. You can demonstrate it simply enough: make a bash script with the single line trap "sleep 20 || echo clean up cancelled!" EXIT ; sleep 10. Run the script and hit ctrl-C twice. You will see that the second ctrl-C is passed to the "clean up" routine (in the trap statement) and terminates its sleep command. – John1024 Jan 15 '14 at 8:43
That's incorrect. Signal delivery is synchronous. If isig is on, as soon as CTRL-C is pressed and received by the kernel (for a terminal emulator, as soon as the terminal emulator writes it to the master side of the pseudo-terminal), the SIGINT signal is sent to all the processes in the foreground process group of the terminal. It may be blocked there, but it's not going to be delivered later to another process. Even if the terminal device buffer is full (the applications have not read any of the things you typed), the CTRL-C will jump the queue. – Stéphane Chazelas Jan 15 '14 at 11:05
Yes, as an example, VLC interprets multiple Ctrl+C signals as a way to quit uncleanly, whereas a single Ctrl+C will attempt to quit cleanly. – Jeremy Visser Jan 15 '14 at 23:05

You're wasting them. All that happens is that once the server finishes with the screen output, it will receive multiple Ctrl-C. The first one will be used to kill the process, and the following ones will end up in your shell, which will then look something like

[user@server]$ ^C
[user@server]$ ^C
[user@server]$ ^C
[user@server]$ ^C
[user@server]$ ^C
share|improve this answer
The process doesn't necessarily exit when sending it a SIGINT. It could stay alive indefinitely and do something different every time Ctrl+C is pressed. – Brian Gordon Jan 15 '14 at 19:44
True. I was making assumptions about how the user is reading the file. – Jenny D Jan 16 '14 at 8:45

You're right. The keypresses are being wasted. When you press Crtl+C and it gets detected, there are resources that need to be cleared, which is why it takes time. The one possible case I know where pressing Ctrl+C is required, is when you want to cancel a Yum update process, where Yum requires you to press Ctrl+C twice to confirm that you really want to cancel.

share|improve this answer

Short answer: If the process reacts to it.

Long answer: When you hit ctrl+c the kernel sends a signal to the process. Which signal can be determined by the following command:

user@host:~# stty -a | grep -i "\^C"
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;

See the man page of stty:

   intr CHAR
          CHAR will send an interrupt signal

It's the signal INT, also known as number 2. When the process has a signal handler it can react to this. Most processes do some cleanup jobs to end successfully.

share|improve this answer
Ctrl-Z usually sends SIGTSTP which can be handled (unlike SIGSTOP). – peterph Jan 15 '14 at 8:33
@peterph I remove the part, thanks – chaos Jan 15 '14 at 8:54
No, it's not the shell that sends the SIGINT to the process. It's the kernel (the line discipline of the terminal, the terminal driver) that sends SIGINT to every process in the foreground process group of the terminal. – Stéphane Chazelas Jan 15 '14 at 10:07
@StephaneChazelas Thanks, I changed it. – chaos Jan 15 '14 at 10:36

I always have to press Ctrlc multiple times. I have never had it respond on the first press, and have to use it multiple times until the system actually realizes there's a Ctrlc being sent. Seems as though it actually misses/loses most of them.

share|improve this answer

Although only one Ctrl-C is necessary in the general case, there are some situations where it may be necessary. Python, for example, traps Ctrl-C when a new thread is being spawned, and so if something goes wrong in the midst of starting up many threads, it is necessary to resend it multiple times in order for it to get through to the python parent process without being caught.

share|improve this answer
This happens to me now and then when I create multi-threaded/processed python scripts. Sometimes several presses are needed before the main process is killed. – Leo Jan 16 '14 at 6:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.