Linux Signals

In Linux, Signals are the interrupts that are sent to the program to specify that an important event has occurred. Events can vary from user requests to invalid memory access errors. Various signals, like the interrupt signal, means that the user has asked the program to perform something which is not present in the user flow of control.

There are two kinds of signals:

Maskable
Non-Maskable
Maskable: - Maskable Signals are the signals that the user can change or ignore, for example, Ctrl +C.
Non-Maskable: - Non-Maskable Signals are the signals that the users cannot change or ignore. Non-Maskable signals mainly occur if a user is signaled for non-recoverable hardware errors.

There are various processes in different states in the Linux computer system. All these processes belong to either the operating system or the user application. A mechanism is required for the kernel and these processes to coordinate their activities. One method to perform this, for the process, to inform others if anything vital occurs. That's the reason we have signals.

Basically, the signal means a one-way notification. The kernel sent the signal to the process, to one process to itself, or another process.
Linux signals trace their origin to Unix signals. In later Linus versions, real-time signals were added. Signal inter process is an easy and lightweight form of communication and is therefore compatible with embedded systems.

What is the Typical Lifecycle of a Signal?

A signal goes through three stages:

Generation
Delivery
Processing

1. Generation

A signal is generated by a process via the kernel. Whichever generates the signal addresses process to a particular process. With the help of the process number, the signal is represented, and it does not contain any additional data or arguments. So, signals are lightweight. However, we can pass the additional signal with POSIX real-time signals. Functions and system calls that can produce signals contain kill, sigqueue, raise, pthread_kill, kill, and tgkill.

2. Delivery

We said that the signal remains pending until it is delivered. Basically, in a small amount of time signal is delivered to the process by the kernel. If the process has blocked the signal, the process will be pending until unblocked.

3. Processing

When the signal is delivered, it is processed in various ways. Each signal contains a default action such as terminate the process, ignore the signal, stop the process, continue the process. For non-default behavior, handler function might be called. Precisely which of these happens is stated through sigactio n function.

Signals List with Meaning

The below table shows the list of the signals along with their meaning:

S.NO.	Signal Name	Meaning
1.	SIGHUP	HUP is a short form of "hang up." Locate the terminal to be controlled or hung up on the death of the control process. This signal is received when the process runs from the terminal, and that terminal goes abruptly.
2.	SIGINT	This signal is released whenever the user sends an interrupt signal (Ctrl + C).
3.	SIGQUIT	The SIGQUIT signal is issued when the user sends the quite signal (Ctrl + D).
4.	SIGILL	It is an Illegal instruction. There is some machine code that is contained in the program, and the CPU cannot understand this code.
5.	SIGTRAP	Mostly the SIGTRAP is used from inside debuggers and program tracers.
6.	SIGABRT	The function named abort () is called by the program. It is an emergency stop.
7.	SIGBUS	SIGBUS is an attempt via which memory is accessed incorrectly. In memory access, it may cause Alignment errors.
8.	SIGFPE	The SIGFPE is the floating-point exception that occurred in the program.
9.	SIGKILL	When the process receives the SIGKILL signal, it has to quit instantly and cannot perform any of the clean-up operations.
10.	SIGUSR1	Left to programmers to do whatever they need.
11.	SIGSEGV	It was attempted to use memory that had not been allocated in the process. This was due to the end readings of arrays etc.
12.	SIGUSR2	Left to programmers to do whatever they need.
13.	SIGPIPE	SIGPIPE signal is used when a process generates output which is being fed to other process consume it through a pipe ("{producer \| consumer"), and then the consumer dies and this signal is then sent to the producer.
14.	SIGALRM	In this, the process may eventually request a "wake up call" from the operating system in the future by calling the function named alarm (). When that time comes, this signal is contained in the wake-up calls.
15.	SIGTERM	This process was apparently done by someone killing the program.
16.	SIGCHLD	This process previously creates one or more child processes with the fork () function.
17.	SIGCONT	(can be read in conjunction with SIGSTOP) When a process is interrupted by sending it the SIGSTOP signal, we must then give it the SIGCONT signal to restart it.
18.	SIGSTOP	(can be read in conjunction with SIGCONT.) If a SIGSTOP signal, is sent to the process, then it is stopped by the operating system. All of it, the state is ready to restart it (by SIGCONT), but until then it gets another CPU cycle.
19.	SIGTSTP	SIGSTP is a short form for "terminal stop." Basically, the SIGTSTOP signal is the same as the SIGTSTP signal. When the user presses Ctrl +Z on the terminal, the SIGTSTP signal is sent.
20.	SIGTTIN	The only difference between SIGTSTP and SIGSTOP is that pausing is only the default action for SIGTSTP but is the needed action for SIGSTOP. This process may choose to handle SIGTSTP differently but is not found options about SIGSTOP.
21.	SIGTOU	When a background process attempts to write output to its terminal. SIGTOU signal is sent by the operating system. The typical response is based on the SIGTTIN.
22.	SIGURG	With the help of the network connection, the SIGURG signal is sent by the operating system whenever the "urgent" out-of- band data is sent.
23.	SIGXCPU	The SIGXCPU signal is sent by the operating system to the process, which crosses its CPU limit. With the shell command ("ulimit -t unlimited"), we can cancel the CPU limit before making a run, although there are more chances that something went wrong if you reach the CPU limit in make.
24.	SIGXFSZ	If there is a process that tried to create a file that is above the file format, then the operating system sends a SIGXFSZ signal. We are also able to cancel the limit of the file size by using the shell command ("ulimit -t unlimited") although it is more likely that something went wrong if we reached the file size limit before the run.
25.	SIGVTALRM	Both SIGVTALR and SIGALRM signals are the same, except that the SIGALRM signal is sent after some amount of real-time has passed while SIGVTALRM is sent after some time has been spent to run the process.
26.	SIGPROF	SIGPROG is just like SIGVTALRM and SIGALRM, whereas SIGALRM is sent after some amount of real-time has passed, SIGPROG is sent after spending some amount of time to run the process, and the system code run on behalf of the process.
27.	SIGWINCH	The SIGWINCH signal is used by the process when any of its windows are resized.
28.	SIGIO	(SIGIO is also called SIGPOLL). A process that can arrange for this signal to be sent is ready to do this when there is some input process or an output channel has agreed to write.
29.	SIGPWR	A power management service sent this signal to the processes in order to show that power had been changed to a short-term emergency power supply.
30.	SIGSYS	Unused

List of Signal

There is a simple method to list each signal that is supported by our system. We have to enter the kill -l command on the terminal, and then it will show you the list of all the supported signals:

Default Actions

There is a default action that is associated with each signal. For a signal, default action means the action which a program or script performs when it receives a signal.

There are various possible default actions:

Stop the process.
Terminate the process
Continue a stopped process.
Ignore the signal
Dump core: This default action generates a file named core which comprise the process's memory image when the process received the signal.

Sending Signals

The Number of methods is used to send signals to a script or program. For a user, the most basic method is to press the INTERRUPT key or CONTROL-C when the script execute.

When we enter Ctrl+C, the SIGINT signal is sent to the script, and, according to the defined default action, the script terminates.

By using the kill command, we can also deliver the signals.

We can also use another method in order to deliver the signal in which we can use the kill command; the following is the syntax of the kill command:

In the above syntax of the kill command, the signal means the signal's name or number, which has to be delivered, and pid means the process's ID that the signal has to be sent. For an example-

The above command sends the signal named hang-up or HUP to the program, which is running with the 1001 process ID. In order to send the kill signal to a similar process, we have to use the below command-

The above-mentioned process ID 1001.command will kill the process which is running with process ID 1001.

Trapping Signal

When we enter Ctrl +C or the break key on our terminal during the execution of the shell program, that program is usually terminated immediately, and our command prompt returns. It might not be desirable every time. For example, we can leave a set of temporary files that will not be cleaned.

It is so simple to trap these signals, and below is the syntax of the trap command:

Here, the command can be any of the valid Linux command, or a user-defined function, and the signal involves any signal which we need to trap.

In shell scripts, there are two basic uses of trap:

Clean up temporary files
Ignore signal

Null Signal

An interesting use case of sending signals is to investigate the existence of the process. When the kill() system is called along with the signal argument as 0 that is a null signal, then no signal is sent, but it can just perform error checking in order to check if the process can be signaled. This means that we are able to use this procedure in order to see the process's existence. At the time, a null signal is sent, then any of the following response can occur:

If an error ESRCH arises, which means the target process does not exit.
If the call is successful, it implies that the target process is present, and the caller is allowed to send a signal to it.
If the error EPERM arises, then it means that the target process exists, but we do not have enough permission in order to send the signal to the process.

What Happens When a Signal Arrives?

At the time, when the signal is close to being delivered, then any of the following default actions happen, based on the signal.

The signal is ignored, which is, the kernel discarded it, and there is an effect on the process. (The process is unaware that the event still took place.)
The process is terminated, i.e., abnormal process termination, as opposed to a normal process termination which arises when a program terminates using the exit() function.
A core dump file is generated, and the process terminates.
The process's execution is resumed or suspended.
Rather than accepting the default actions of a specific signal, a process may set the action of a signal by modifying the action which arises at the time when the signal is delivered. A program can set any of the following actions:
1. The default action must arise. This is helpful for undoing the first modification of the signal to something other than its default.
2. The signal is unnoticed rather than the default action to end the process.
3. An established signal handler can be executed. The signal handler means the custom-tailored function which performs the right functions in response to signal delivery. Informing the kernel that the handler function has to be invoked if a signal arrives is called installing or establishing a signal handler. Until one of these signals has a default disposition, we cannot determine the disposition of the signal in order to terminate or dump core.
There are two signals SIGSTOP and SIGKILL, that cannot be blocked, ignored, or caught.