Ctrl + C doesn't always work to kill the current process (for instance, if that process is busy in certain network operations). In that case, you just see "^C" by your cursor and can't do much else.

What's the easiest way to force that process to die now without losing my terminal?

Summary of the answers: Usually, you can Ctrl + Z to put the process to sleep, and then do kill -9 _process-pid_, where you find the process's pid with ps and other tools. On Bash (and possibly other shells), you can do kill -9 %1 (or '%N' in general) which is easier. If Ctrl + Z doesn't work, you'll have to open another terminal and kill from there.

  • screen would be a possible solution, Allowing you to create a new window and kill the process from there.
    – Bobby
    Feb 9 '11 at 8:54
  • 3
    assuming you were already in a screen :) Feb 9 '11 at 8:56

10 Answers 10


To understand the problem of why Ctrl + C does not work, it is very helpful to understand what happens when you press it:

Most shells bind Ctrl + C to "send a SIGINT signal to the program that currently runs in the foreground". You can read about the different signals via man signal:

 SIGINT        2       Term    Interrupt from keyboard

Programs can ignore that signal, as they can ignore SIGTSTP as well:

 SIGTSTP   18,20,24    Stop    Stop typed at tty

(Which is what most shells do when you press Ctrl + Z, which is why it is not guaranteed to work.)

There are some signals which can not be ignored by the process: SIGKILL, SIGSTOP and some others. You can send these signals via the kill command. So, to kill your hanging / zombieying process, just find the process ID (PID). For example, use pgrep or ps and then kill it:

 % kill -9 PID
  • 14
    A mere remark. Beware that "zombie" is technically a process state, and it is not the same as what you meant here by "zombieying". (A terminated process which has not been wait()-ed by its parent is in zombie (Z) state. In this case, it cannot handle signals anymore.) Sep 19 '11 at 14:15
  • 1
    alas, sometimes ctrl+c, ctrl+z, and ctrl+\ all do nothing, and the process is running undo sudo (permitted without a password) so you can't just send a signal to the process.
    – Michael
    Jan 30 '18 at 19:50

If Ctrl+C (SIGINT) doesn't work, try Ctrl+\ (SIGQUIT). Then try Ctrl+Z (SIGTSTP). If that returns you to a shell prompt, do kill on the process ID. (This defaults to the SIGTERM signal, which you can specify with kill -TERM. In some shells, you may be able to use %1 to refer to the PID.) If that doesn't work, go to another terminal or SSH session and do kill or kill -TERM on the process ID. Only as a last resort should you do kill -KILL, a.k.a. kill -9, as it doesn't give the process any chance to abort cleanly, sync its open files, remove its temporary files, close network connections, etc.


See this link as well.

Ctrl+Z: pause a process.

Ctrl+C: politely ask the process to shut down now.

Ctrl+\: mercilessly kill the process that is currently in the foreground

  • 6
    "ctrl"+"\" didn't work for me Jan 2 '19 at 7:26
  • 2
    Your description of Ctrl+\ is inaccurate. This sends a SIGQUIT, which does not necessarily kill the process, and certainly not "mercilessly". It does typically do so, after triggering a core dump. However if a process is ignoring SIGINT it's entirely plausible it will ignore SIGQUIT too. There is nothing "merciless" about SIGQUIT; you're thinking of SIGKILL.
    – dimo414
    Jun 19 '20 at 22:06

Press Ctrl-Z to suspend the program and put it in the background:

Suspend the program currently running and put it in the background.
This does not stop the process as it does in VMS!

(Restore to foreground again using fg)

Then, you can kill or kill -9 it, given its process ID (you get that from ps a).

  • 13
    With bash you can kill $!, as $! is a special variable containing the pid of the last backgrounded program.
    – Lloeki
    Feb 9 '11 at 12:58
  • @Lloeki Doesn't work for me (at least not reliable). I have to bg once before the variable gets a value assigned.
    – Daniel Beck
    Feb 9 '11 at 13:10
  • 2
    @Daniel, correct. It is as I said the last backgrounded process, thus needs bg as right after Ctrl+Z it is merely suspended.
    – Lloeki
    Feb 9 '11 at 13:22
  • 2
    Note: this is not just a trick, using ps output (or killall) is quite risky if you have multiple processes with the same name running. ps -e -o pid,command will provide pid+full args, not just program name, but again might not be enough to discriminate. In contrast $! is a sure hit.
    – Lloeki
    Feb 9 '11 at 14:07
  • 1
    @Lloeki I disagree. Example output line from ps a on my system: 27721 s000 T 0:00.09 top How many suspended (T, I think) instances of the same command (top) do you have running in the same tty (s000)?
    – Daniel Beck
    Feb 9 '11 at 17:30

Usually, you can still stop the process (Ctrl + Z) and then use kill -9. For kill -9, you need the process PID first. For background jobs, kill -9 %1 is easiest way to do it - if you are unsure what is the number of background job you want to kill, run jobs.

Alternatively, you can find process ID with


Then you can run

kill -9 <Appropriate PID from ps output>

A simpler solution for Bash (and other shells?) is to do:

Ctrl-z      followed by     kill -9 %1

where '%1' refers to the job number being killed. It might be '%2' (or something else) if you already have other jobs sleeping. You can see which job number it is when you hit Ctrl-z:

[1]+  Stopped                 <process name>

Note that 'kill' is the shell's version of kill, not /bin/kill.


1) If you are on the console and in multi-user mode, you could press CTRL-ALT-Fn and login on another screen, use ps -ef | grep <myprocessname> or pidof <myprocessname> and then kill -9 the process by ID number.

2) If you are connected remotely, do the same via another terminal session.

You could also make life a little easier by installing htop, which is a more versatile version of top that allows you to selectively kill running processes. Most distros have htop in a repo.

3) if you are just stuck in a hung ssh session (to another system, for example), try pressing tilde (~), which is the escape key, and then press CTRL-Z to drop back to the host session, then you can kill the stuck ssh process or wait for it to timeout, which most sill do after a period of inactivity.


If you are using tmux or screen, and none of the above works, you could still kill the pane by <prefix> x, then the process is also killed.


There maybe a trap set with SIGINT(2) in your /etc/profile. If so, remove it. Logout and log back in and you should be good.


I suggest checking your intr setting with 'stty -a'. It's possible to rebind it to another character. For instance, today this same behavior started happening to me, in just a single xterm, I spent about 10 minutes stracing various things and looking at the environment, before typing 'stty -a', at which point I found my intr key rebound to '^E'.

How this happened is a real mystery, but I was able to fix it with stty intr ^V^C.

When special keys don't work right, it's always good to check stty. A few years ago, I had to use an old HP-UX system that bound kill-line to the old System V '@' character.

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.