246

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?

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

11 Answers 11

169

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

The kernel tty driver causes a Ctrl + C to "send a SIGINT signal to the attached process. 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
9
  • 16
    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, 2011 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, 2018 at 19:50
  • But how can you find the PID when nothing is responding? I have a du command that is printing an update every 120 seconds, but anything I type does not do anything. Aug 29, 2022 at 2:57
  • 1
    @JaydenLawson: for those situations the last paragraph is meant for
    – akira
    Sep 1, 2022 at 12:30
  • @Michael: you can send any process a signal … if you know its PID.
    – akira
    Sep 1, 2022 at 12:31
148

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.

1
  • My terminal just displayed ^C each time I press Ctrl+C, ^Z when I press Ctrl+Z, and `^` when I press Ctlr+\ Oct 6, 2022 at 16:52
53

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

2
  • 7
    "ctrl"+"\" didn't work for me Jan 2, 2019 at 7:26
  • 8
    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, 2020 at 22:06
35

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).

7
  • 15
    With bash you can kill $!, as $! is a special variable containing the pid of the last backgrounded program.
    – Lloeki
    Feb 9, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 17:30
14

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

ps

Then you can run

kill -9 <Appropriate PID from ps output>
6

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.

5

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.

0

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.

0

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.

0

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.

0

If you are inside an ssh session, and you don't mind killing it, the escape sequence ~. would kill the session, which would normally kill the hung process as well.

You could then log back in and check that the process is gone. If it's still there then you are now free to do kill -9 <PID of the damned thing>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .