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?
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
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.
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).
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>
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.
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>
I sometimes find that ^C just prints ^C but ^Z backgrounds the task.
I can ^Z and kill the task, but reset and stty sane do not fix it.
I found that although trap prints nothing,
trap '' INT ; trap INT
does fix it. Probably trap INT would suffice alone, but I can't reproduce whatever random thing caused it in the first place.
I'm on Mac zsh.
