If using signals one must remember that they will only be able to be processed when the process is in user mode, if you have sent a signal to a process and at that exact time it is in kernel mode, it will only be processed when the process is back in user mode.
In a way all that you are doing with a signal is sending a process a very simple message.
Let's use an example that will clarify what I mean: If you want to stop a shell process, the only signal that will stop it is the SIGKILL, which is represented by a -9 switch. So you would use the following command:
# kill -9 PID
It is not always so clever to use a -9 switch with the kill command, this means stop that process no matter what. Well that is OK if you are sure of what is going on in your system, but if for example, you were to kill a database process in that way you may corrupt the entire database. (MySQL)
As we saw from the previous section on IPCs, signals are grouped with the other inter-process communication tools.
Signals can be sent to a process in one of the following ways:
By a keyboard interrupt sequence <DEL>
Errors conditions (some that would produce a core dump) that arise, for example if the process attempts to access a portion in memory that does not exist.
Mostly they are used in the shell or in shell scripts and in this way communicate with the child processes.
A process can ignore the receipt of a signal, except in two cases and that is if receiving a SIGKILL signal or a SIGSTOP signal. A process will only be prepared to receive a signal from the same UID or GID or the process owner - unless root overrides this
Other than those two signals it is pretty much up to the process as to how a signal is handled. For example, if the process hands the signal over to the kernel then the kernel will ONLY run the default value of the signal, so if the kernel receives a signal to run a SIGFPE that means that the kernel must dump the core of that process and then exit.
When Linux uses a signal on a process, the information that it needs to run the signal is stored in the task_struct for that process. The information on how a process must handle a signal is kept by Linux for each and every process.
The number of signals that are supported on a machine depends on the word size of the processor, 32 bit means 32 signals, 64 bit means 64 signals.
This table was downloaded from the following site: http://www.comptechdoc.org/os/linux/programming/linux_pgsignals.html
|SIGINT||2||Terminal interrupt (ANSI)|
|SIGQUIT||3||Terminal quit (POSIX)|
|SIGILL||4||Illegal instruction (ANSI)|
|SIGTRAP||5||Trace trap (POSIX)|
|SIGIOT||6||IOT Trap (4.2 BSD)|
|SIGBUS||7||BUS error (4.2 BSD)|
|SIGFPE||8||Floating point exception (ANSI) - dumps core|
|SIGKILL||9||Kill(can't be caught or ignored) (POSIX)|
|SIGUSR1||10||User defined signal 1 (POSIX)|
|SIGSEGV||11||Invalid memory segment access (ANSI)|
|SIGUSR2||12||User defined signal 2 (POSIX)|
|SIGPIPE||13||Write on a pipe with no reader, Broken pipe (POSIX)|
|SIGALRM||14||Alarm clock (POSIX)|
|SIGCHLD||17||Child process has stopped or exited, changed (POSIX)|
|SIGCONT||18||Continue executing, if stopped (POSIX)|
|SIGSTOP||19||Stop executing(can't be caught or ignored) (POSIX)|
|SIGTSTP||20||Terminal stop signal (POSIX)|
|SIGTTIN||21||Background process trying to read, from TTY (POSIX)|
|SIGTTOU||22||Background process trying to write, to TTY (POSIX)|
|SIGURG||23||Urgent condition on socket (4.2 BSD)|
|SIGXCPU||24||CPU limit exceeded (4.2 BSD)|
|SIGXFSZ||25||File size limit exceeded (4.2 BSD)|
|SIGVTALRM||26||Virtual alarm clock (4.2 BSD)|
|SIGPROF||27||Profiling alarm clock (4.2 BSD)|
|SIGWINCH||28||Window size change (4.3 BSD, Sun)|
|SIGIO||29||I/O now possible (4.2 BSD)|
|SIGPWR||30||Power failure restart (System V)|
These signals are generated by processes or the kernel to notify other processes that an event has occurred.