Ending a process in Unix instead of interrupting it

Question

At the Unix command line if I press Ctrl-C,that does not end a process, but rather interrupts it and I return to the shell prompt.

So, I have the following two questions:

• 1. Is there a way i can see the list of all interrupted processes and end them?
• 2. What key combination to press to end a process instead of interrupting it ?

Answer 1

Ctrl+C sends a SIGINT. By default this terminates the application.

You are confusing this with Ctrl-Z, which suspends an application in bash.

Answer 2

Historically there were three signals bound to keystrokes these were

• SIGINT (Intettput) usually Ctrl+C or Del
• SIGQUIT - Quit - Usually bound to Ctrl+\
• SIGSUSP Suspend - Usually bound to Ctrl+Z

On some *nix flavours there are other signals also bound, you can check the keyboard bindings using the command

stty -a

On my system, OS/X, this produces the following output

speed 9600 baud; 65 rows; 213 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
    -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
    -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
    -ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
    -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
    eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
    min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
    stop = ^S; susp = ^Z; time = 0; werase = ^W;

Please note kill in this instance is not a KILL signal it is to do with clearing the current input buffer.

You may have more success with stopping processes using SIGQUIT, but this may not be true as the process may catch the signal and ignore it.

There is no concept of a list of "interrupted" processes as the process has either caught and ignored the interrupt or it has exited. You can get a list of suspended processes by typing jobs

Answer 3

Lots of correct answers, but none that are complete.

1. As many others have said: Control-C typically sends the unix signal SIGINT and the default behavior (from programs that don't override it) is "terminate process". The program can ignore this signal or take a different action if it desires.
2. You can also send SIGQUIT from the keyboard with Control-\. The difference here is that by default the process will write a core file, then quit. The program can ignore this signal or take a different action if it desires.

3. To terminate with extreme prejudice and without allowing the process to stop you use SIGKILL, which is not bound to any key by default. Instead you generally send it using the kill (1) command and specifying the signal to send as in

   $ kill -9 <process ID>
   

   or mnemonically

   $ kill -KILL <process ID>
   

   This signal is handled directly by the OS and the program can not override the default behavior.

4. If your shell supports job control it may also support a built in version of kill which supports job identification using the % character as in catwalk's answer.

5. To pause a process in a resume-able way you use Control-z which sends SIGTSTP. You resume such a process with either fg to continue in control of the terminal or bg to set it running without keeping control of the terminal (but, by default, still sending its output there).

Answer 4

This is not clear to most terminal newbies, but if your issue is just that you are in an interactive program and you can't figure out how to get out, quite often q will exit. For example, this is the key to exit less, which is also the program you get when you view man pages, among other things.

Some programs have other keyboard shortcuts to exit. In vim or vi, use ESC:wq. In emacs, use Control-C Control-X. In nano or pico, use Control-X. Note that in these examples there are subtleties, in particular, concerning whether or not those shortcuts save any changes you may have made to the file you are editing.

Answer 5

1. to see list of background processes: jobs

   to kill: kill %1 (substitute 1 with corresponding job id as in jobs output)

2. see here

Answer 6

Ctrl-C sends SIGINT, which by default causes a process to end, but can be trapped (in \bin sh, using trap).

SIGKILL is the untrappable kill signal.

Edit Third time, I think this is right: I've checked everything against the docs. We'll see.

Answer 7

Many processes can install an interrupt handler to catch the interrupt signal, but those which don't will abort by default.

To force a process to quit, you can send SIGQUIT (Ctrl-\).

Answer 8

It seems the other answers are the likely scenario, but it is also possible that you are executing a script that doesn't handle its children correctly. I recently hit a similar scenario, where killing a script would not kill the child processes of that script.

In general, if you get into this situation, you'll have to review all the processes that you are running. You should review the manpage for ps. (man ps) I particularly like using ps auxwf, which shows the parent/child relationship between processes. pstree does something similar. You should run this from another terminal before killing the process to see what things look like in the normal situation, and identify the child processes.

If you then kill (with ^C) that main process, check the output of ps again to see if anything has changed. If the child processes are still around, you can kill them with the kill command. (see man kill)