What are Processes?
Processes, in effect, are the living result of running program code.
From Linux Kernel Development 3rd Edition by Robert Love.
Signals
SIGHUP
This signal indicates that someone has killed the controlling terminal.
For instance, lets say our program runs in xterm or in gnome-terminal. When someone kills the terminal program, without killing applications running inside of terminal window, operating system sends SIGHUP to the program. Default handler for this signal will terminate your program.
SIGINT
This is the signal that being sent to your application when it is running in a foreground in a terminal and someone presses CTRL-C. Default handler of this signal will quietly terminate your program.
SIGQUIT
Again, according to documentation, this signal means "Quit from keyboard".
In reality I couldn’t find who sends this signal. It can only be sent explicitly by CTRL-\.
SIGILL
Illegal instruction signal. This is an exception signal, sent to your application by the operating system when it encounters an illegal instruction inside of your program.
Something like this may happen when executable file of your program has been corrupted. Another option is when your program loads dynamic library that has been corrupted. Consider this as an exception of a kind, but the one that is very unlikely to happen.
SIGABRT
Abort signal means you used used abort() API inside of your program. It is yet another method to terminate your program. abort() issues SIGABRT signal which in its term terminates your program (unless handled by your custom handler). It is up to you to decide whether you want to use abort() or not.
SIGFPE
Floating point exception.
This is another exception signal, issued by operating system when your application caused an exception.
SIGSEGV
This is an exception signal as well.
Operating system sends a program this signal when it tries to access memory that does not belong to it (segmentation fault/segfault, memory access violation, a core dump will be generated by default).
SIGPIPE
Broken pipe. As documentation states, this signal sent to your program when you try to write into pipe (another IPC) with no readers on the other side.
SIGALRM
Alarm signal. Sent to your program using alarm() system call. The alarm() system call is basically a timer that allows you to receive SIGALRM in preconfigured number of seconds. This can be handy, although there are more accurate timer API out there.
SIGTERM (15)
This signal tells your program to terminate itself. Consider this as a signal to cleanly shut down while SIGKILL is an abnormal termination signal.
SIGKILL (9)
On the contrary to SIGTERM, indicates abnormal termination of the program. You cannot change how your program handles it. It will always terminate your program. However, you can send this signal.
SIGCHLD
Tells you that a child process of your program has stopped or terminated. This is handy when you wish to synchronize your process with a process with its child.
SIGUSR1 and SIGUSR2
Finally, SIGUSR1 and SIGUSR2 are two signals that have no predefined meaning and are left for your consideration. You may use these signals to synchronise your program with some other program or to communicate with it.
Signals sent by Keyboard
- Ctrl-c SINGINT
- Ctrl-z SIGTSTP
- Ctrl-\ SIGQUIT
NOTE: print Terminal Control Characters by using stty -a
SIGTERM VS SIGKILL
Anytime you use kill on a process, you're actually sending the process a signal (in almost all situations - I'll get into that soon). Standard C applications have a header file that contains the steps that the process should follow if it receives a particular signal. You can get an entire list of the available signals on your system by checking the man page for kill.
Consider a command like this:
kill pid
This would send a signal called SIGTERM to the process. Once the process receives the notice, a few different things can happen:
- the process may stop immediately
- the process may stop after a short delay after cleaning up resources
- the process may keep running indefinitely
The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.
Most system administrators will usually resort to the more abrupt signal when an application doesn't respond to a SIGTERM:
kill -9 pid
The -9 tells the kill command that you want to send signal #9, which is called SIGKILL. With a name like that, it's obvious that this signal carries a little more weight.
Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn't even made aware of the SIGKILL signal since the signal goes straight to the kernel init. At that point, init will stop the process. The process never gets the opportunity to catch the signal and act on it.
However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won't be able to stop it. Zombie processes and processes caught in an uninterruptible sleep cannot be stopped by the kernel, either. A reboot is required to clear those processes from the system.
Reference
http://rackerhacker.com/2010/03/18/sigterm-vs-sigkill/
http://www.howtogeek.com/119815/htg-explains-what-is-a-zombie-process-on-linux/