Signals are an older form of communication than the SysV mechanisms. Although they provide fewer options, they are generally very suited to their purpose. The underlying concept is very simple — the kill command sends a signal to a process identified by its PID. The number of the signal is specified using -s sig and is a positive integer whose maximum size varies depending on processor type. The two most frequently used variants of the command are kill without a signal number, which politely requests the process to terminate (the process is free to ignore the signal), and kill -9, which is the equivalent of a signature on an execution warrant (and results in certain death).
In the past, 32-bit systems supported a maximum of 32 signals, but this restriction has now been lifted, and all signals listed on the kill manual page are now supported. Nevertheless, all the "classic" signals occupy the first 32 positions on the list. They are followed by new signals introduced for real-time processes.
Processes must install handler routines to process signals. These are invoked when signals are sent to the processes (but there are several signals such as SIGKILL whose behavior cannot be overridden). If no explicit handler routine is installed, the kernel uses a default handler implementation.
Signals introduce several special features that must always be kept in mind. A process can decide to block specific signals (sometimes referred to as the masking of signals). If this happens, the signal is ignored until the process decides to remove the block. There is therefore no guarantee that a process will be aware that a signal has been sent to it. When a signal is blocked, the kernel places it on a pending list. If the same signal is blocked more than once, only a single occurrence of the signal is placed on the pending list. No matter how many identical signals are sent, the process receives just one occurrence of the signal when it removes the block.
The SIGKILL signal cannot be blocked and cannot be handled by a process-specific handler function. It cannot be overridden because it is the last resort to remove an out-of-control process from the system. This contrasts with the SIGTERM signal, which can be dealt with by a user-defined signal handler — after all, the signal is just a polite request to the process to stop work as soon as possible. If a handler is installed for this signal, the program is, for example, given the opportunity to save data or to ask users whether they really want to exit the program. SIGKILL does not provide such opportunities because the kernel brings the process to an immediate and abrupt end.
The init process is granted a special status. The kernel ignores any sigkill signals sent to it. Because this process is of particular importance to the entire system, it may not be forced to terminate — not even unintentionally.
Continue reading here: Implementing Signal Handlers
Was this article helpful?