Signals

Signals
	Chapter 8. Tips and Tricks

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

	Note
	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

Signal Name	Number	Description
SIGHUP	1	Hangup (POSIX)
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)
SIGTERM	15	Termination (ANSI)
SIGSTKFLT	16	Stack fault
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.


Inter-Process Communication		Appendix A. Referances