236

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.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
Dustin Boswell
  • 2,471
  • 4
  • 19
  • 11

12 Answers12

162

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
stevea
  • 103
  • 2
akira
  • 61,009
  • 17
  • 135
  • 165
  • 15
    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.) – Stéphane Gimenez 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
  • 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. – Jayden Lawson Aug 29 '22 at 02:57
  • 1
    @JaydenLawson: for those situations the last paragraph is meant for – akira Sep 01 '22 at 12:30
  • @Michael: you can send any process a signal … if you know its PID. – akira Sep 01 '22 at 12:31
  • Not if sudo isn't set up to let you do that. – Michael Sep 01 '22 at 14:56
  • Notice the signal is actually defined in `/usr/include/bits/signum-generic.h`, which is imported by `/usr/include/signal.h` – robertspierre Jan 02 '23 at 07:49
  • @Michael: yes, you can. it just doesn't do anything if you do not have permissions. if you need to send `a signal` to a process for which your regular user does not have permissions: then you need to gain access, it is as simple as that. but what is your point with your comment? that the os prevents one user from killing process of another user? that is by design. – akira Feb 17 '23 at 06:18
  • @akira Haha I don't remember what I was thinking 5 1/2 months ago, but I assume that I found the idea that you could send any process a signal incorrect - and what is the difference between not being able to send a signal, and sending a signal and having it not do anything? They both have the same result. – Michael Feb 17 '23 at 22:33
146

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.

G-Man Says 'Reinstate Monica'
  • 7,678
  • 22
  • 41
  • 87
Teddy
  • 6,848
  • 4
  • 19
  • 19
52

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

Community
  • 1
RoboAlex
  • 621
  • 5
  • 6
  • 7
    `"ctrl"`+`"\"` didn't work for me – Benyamin Jafari Jan 02 '19 at 07: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](https://en.wikipedia.org/wiki/Signal_(IPC)#SIGQUIT). 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
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).

akira
  • 61,009
  • 17
  • 135
  • 165
Daniel Beck
  • 109,300
  • 14
  • 287
  • 334
  • 15
    With bash you can `kill $!`, as `$!` is a special variable containing the pid of the last backgrounded program. – Lloeki Feb 09 '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 09 '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 09 '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 09 '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 09 '11 at 17:30
  • Indeed, it seriously reduces the field of action: (tty, status) makes it unique most of the time. – Lloeki Feb 10 '11 at 15:56
  • +1 for the `fg` thing. I accidentally pressed `CTRL+Z` on a program and `kill` wouldn't kill it. `fg` brought the program back and killed it. – Eduard Luca Feb 21 '19 at 21:54
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>
Olli
  • 7,571
  • 3
  • 34
  • 47
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.

Dustin Boswell
  • 2,471
  • 4
  • 19
  • 11
4

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.

Linker3000
  • 27,498
  • 3
  • 52
  • 73
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.

ospider
  • 101
  • 2
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.

TechNo_phile
  • 1
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.

Allen Garvin
  • 1
  • 1
0

For those who are using VM, you can also try the code below to stop the running process;

Ctrl + Alt + C
Turhan Ergene
  • 101
  • 2
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>

Rolf
  • 315
  • 3
  • 10