I have looked for answers and so far have found nothing to answer my question. I am currently logging in to my Ubuntu server and upon running a process I can not run any of the interrupts on it. Here is my stty -a:

user@Ubuntu1:~$ stty -a
speed 38400 baud; rows 93; columns 200; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;

I have nothing in my .bashrc that changes the interrupts.

This is the same for all the users including root. I have also tried logging in from different locations using different terminals and every time this same result appears. I have used both ssh and ssh -X to log in.

Edit: Locally all my interrupts work fine.

Update: I am still looking for an answer. My friend has exactly the same problem. The issue seems very much to be that when logging in (from PC, Mac, Linux) the keyboard is not picking up these keys (even though correctly mapped).

  • What's the output of Ctrl+V and hitting Ctrl+C? Have you tried killing the process with kill -s 2 <pid_of_process>? This is should be equal to sending the SIGINT signal to the process. Check your terminal emulator key settings.
    – user13742
    Feb 14, 2012 at 14:03
  • The output is correct. If I do the following Ctrl+V and then Ctrl+C I get ^C. I get the same if I do Ctrl+V and then Ctrl+Z I get ^Z. I can kill processes with kill if i do this from another terminal. Also so note locally and in other terminals these commands work fine
    – user700786
    Feb 14, 2012 at 14:35
  • 3
    Have you tried hitting Ctrl+C while running another process (e.g. cat)? Maybe it's that process that ignores Ctrl+C. Or do you mean that locally on the Ubuntu server, that particular process responds to Ctrl+C, in which case, in what terminal did you try? What about a screen session? Feb 14, 2012 at 15:49
  • If I run anything in the terminal on my machine then it will pick up the interrupts no problem. Its as soon i ssh into my server that it will not pick up the interrupts. None of the processes I have tried pick up any interrupts
    – user700786
    Feb 14, 2012 at 20:31
  • If the command gets killed with kill -s 2 (note the -s 2, that's SIGINT (the signal that's usually sent when you hit Ctrl+C, the default for kill is SIGTERM)), then the command is not ignoring the interrupt. Something else is picking it up. When you run this locally and it works, are you saying it works using the same terminal in the client machine to run something locally, or running a terminal emulator locally in the server machine? I wonder if you're using some emulator that is trying to mimick Ctrl+C from the Windows world...
    – njsg
    Mar 6, 2012 at 8:56

5 Answers 5


ctrl+c doesn't ever kill a program,

That's just not what it does.

There are a set of signals that the POSIX standard define, these are used to control a running program.

  First the signals described in the original POSIX.1-1990 standard.
  Signal     Value     Action   Comment
  SIGHUP        1       Term    Hangup detected on controlling terminal
                                or death of controlling process
  SIGINT        2       Term    Interrupt from keyboard
  SIGQUIT       3       Core    Quit from keyboard
  SIGILL        4       Core    Illegal Instruction
  SIGABRT       6       Core    Abort signal from abort(3)
  SIGFPE        8       Core    Floating point exception
  SIGKILL       9       Term    Kill signal
  SIGSEGV      11       Core    Invalid memory reference
  SIGPIPE      13       Term    Broken pipe: write to pipe with no
  SIGTERM      15       Term    Termination signal

- http://man7.org/linux/man-pages/man7/signal.7.html

ctrl+c sends signal 2, "Interrupt from keyboard" to the program you've run from a terminal.

Its entirely up to the program to handle that signal, it can do whatever it wants about it. Many scripting language interpreters may handle this in a default way by killing the called script and exiting gracefully.

If you want a program to exit, espeically from an automatic context, singal 15 is recommended, the kill program can be used to send signals to a process by id (pid).

kill -15 <pid>

As far as I'm aware, the program still receives this signal itself, and should terminate ASAP as cleanly as it can do so.

If the program ignores signal 15 though, And the program persists to live (and you aren't failing to send the signal due to a permission error)

kill -9 <pid>

Signal 9, as far as I am aware, is interpreted by the kernel (the task manager, and hardware interface), The kernel abruptly stops processing the program, and de-allocates/frees all of its resources.


Here is some hardcore trick:


it will suspend your process and it'll return you the job ID of that process


kill -9 %1

(replace 1 with your job ID).

Note: Percentage is mandatory!, otherwise you'll kill your init process which means you will kill the kernel and the whole system will crash (so don't put the space in between :)


If I had to guess, it's because you probably have Ctrl+C mapped to "Copy" in your terminal settings. If you change it to Ctrl+Shift+C, then Ctrl+C will work properly again for stopping processes.


Ctrl+c will not kill the process. it will just stop the current running process in the middle. To kill the process we need to use "KILL" command

  • 8
    In fact kill sends a signal to a process. Doesn't kill it.The default signal sent with kill is TERM, the signal sent with ctrl+c is SIGINT.
    – fmanco
    Jul 11, 2012 at 15:22

I ran into this old forum post about this particular issue. It appears the default interrupt sequence could be overridden in a separate config file somewhere.

If you are just looking to kill this process externally you can use kill just beware that you should escalate kill as outlined in this article on killing processes, rather than just jump to the most extreme kill -9.

Wikipedia is a great resource for the kill program. Also here is a list of Unix signals and what they do.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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