Signal Handling In Linux Through The signal() Function

A signal is a message or notification issued to your program by the operating system or another application (or one of its threads). Each signal is assigned a number between 1 and 31. Signals are devoid of argument, and most of the time, their names are self-explanatory. For instance, signal number 9 or SIGKILL notifies the program that it is being attempted to be killed.

List of Signals

There is a simple method for compiling a list of all the signals your system supports. Simply type the kill -l command to see all the allowed signals.

kill -l

Types of Signals

• SIGHUP- This signal indicates that the controlling terminal has been killed. HUP is an abbreviation meaning “hang up.” Locate the terminal to be controlled or hang up on the control process’s demise. This signal is obtained when the process is performed from the terminal and that terminal abruptly terminates.
• SIGINT- This is the signal generated when a user presses Ctrl + C from the keyboard. 
• SIGQUIT- This is the signal generated when a user presses Ctrl + D from the keyboard. 
• SIGILL- Signal for illegal instruction. This is an exception signal provided by the operating system to your application when it detects unlawful instruction within your program. For example, if some code is not understandable by your machine or if your program’s executable file is corrupted. Another possibility is that your program loads a corrupted dynamic library. 
• SIGABRT- Abort signal indicates that you used the abort() API within your program. It is used to end a program. abort() generates the SIGABRT signal, which terminates your program (unless handled by your custom handler). 
• SIGFPE- Exception for floating point numbers. Another exception signal is generated by the operating system when your program causes an exception.
• SIGPIPE- Broken pipe. When there is nothing to read on the other end, write to the pipe.
• SIGSEGV- This is also an exception signal. When a program tries to access memory that does not belong to it, the operating system gives that application this signal.
• SIGALRM- Alarm Signal sent through the alarm() system function to your program. The alarm() system call essentially acts as a timer that allows you to receive SIGALRM after a set amount of time. Although there are other timer APIs that are more accurate, this can be useful.
• SIGTERM- This signal instructs your program to quit. While SIGKILL is an abnormal termination signal, think of this as a signal to cleanly shut down.
• SIGCHLD- Informs you that a child’s process of your program has ended or stopped. This is useful if you want to synchronize your process with one that has children.
• SIGUSR1 and SIGUSR2- SIGUSR1 and SIGUSR2 are two undefined signals that are provided for your consideration. These signals can be used to communicate with or synchronize your software with another program.

Signal as interrupt

• Signals disrupt your program in addition to being instructive. 
• For example, one of the threads in your application must briefly switch to signal handler mode in order to process a signal. 
• As of the Linux kernel version 2.6, it should be noted that most signals only interrupt one thread, as opposed to the previous practice of interrupting the entire application.
• Additionally, a signal handler itself may be halted by a different signal.

Signal masks

Each signal has one of three possible states:

• For the signal, we might have our own signal handler.
• The default handler may be used to handle a signal. Each signal has a default handler job that it performs. For instance, your application will be terminated by the SIGINT default handler.
• The signal could be overlooked. Signal blocking is another name for ignoring a signal.

It is frequently simpler to handle a “signal mask” when manipulating signals and controlling signal setup. Each bit in a bit-mask has a matching signal. Since there are 32 (really 31, since 0 doesn’t count) different signals, we can store information about 32 signals in a single 32-bit integer (unsigned int). 

The operating system does exactly this. Signal masks are also utilized as arguments in other system calls, so we will need to work with them. Default signal handlers are assigned by the C library. This means that even if you ignore signals, your software will still process them and act on them as it would normally. 

What signals are good for?

As their name suggests, signals are used to signal something. There are various signal types, and each one denotes a different meaning. Each signal’s designation is determined by its semantics. In other words, you might wish to select what action should be connected to each of the signals. You might determine that your application would print anything or draw something on the screen in response to a certain signal. Most of the time, it is your choice. There is, however, a standard norm for what each and every signal should do. This accepted practice states that SIGINT should force your program to end. It is in your best interest to maintain this as the SIGINT signal’s default response. Usability is an issue. Nobody desires a non-interruptible program.

Signals that report exceptions

Signals can also be used to suggest that something unpleasant has transpired. For instance, the operating system sends a SIGSEGV signal to your application when your software creates a segmentation failure.

Other uses of signals

There are various uses for signals. 

• Debuggers, for example, depend on signals to receive events regarding programs that are being debugged. 
• One of the so-called IPC – Inter-Process Communication – techniques are called signals. IPC once allowed processes to communicate with one another, as the acronym suggests.
• Another frequent application is when a user wants our program to restart itself rather than the end. In this scenario, the user can use software called kill to send a signal to our program from the terminal. This program might be one you’re already acquainted with. Previously, it killed processes. In actuality, it does convey a signal. Each signal is identified by a unique number. It can transmit any signal, but by default, it sends signal 15 or SIGTERM.

Signal Handler

You can register your own signal handler using one of the various interfaces.

1. signal()

The oldest one is this one. It takes two arguments: a reference to a signal handler code and a signal number (one of those SIGsomethings). A single integer input representing a sent signal number is taken by the signal handler function, which returns void. In this manner, you can apply the same signal handler function to numerous signals.

Syntax:

signal(SIGINT, sig_handler);

Signal() allows you to specify the default signal handler that will be utilized for a specific signal. You can also instruct the system to disregard a certain signal. Choose SIG IGN as the signal handler if you want to ignore the signal. Set SIG DFL as the signal handler to restore the default signal handler.

Even when it appears to be everything you would need, it is preferable to stay away from employing signal (). This system call has a problem with portability. In other words, it acts differently under various operating systems. There is a more recent system call that performs all the functions of signal() while additionally providing a little bit more details about the signal itself, its origin, etc.

2. sigaction()

Another system call that modifies the signal handler is sigaction(). 

Syntax:

int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

A signal number is specified in its first argument. Pointers to the sigaction structure are provided as the second and third arguments. This structure describes how the given signal should be handled by the process.

Usage of signal()

• For the signal with a number signum, the signal() system function installs a new signal handler. The signal handler is set to sighandler, which can be either SIG_IGN or SIG_DFL or a user-specified function.
• The following occurs when a signal with the number signum arrives. The signal is disregarded if the relevant handler is set to SIG_IGN. The signal’s default action takes place if the handler is set to SIG_DFL. Finally, if the handler is a function called sighandler, sighandler is executed after the handler has been reset to SIG_DFL or the signal has been blocked, depending on the implementation.
• “Catching the signal” refers to using a signal handler function for a signal. SIGKILL and SIGSTOP signals cannot be intercepted or disregarded.
• The signal() function either returns SIG ERR on failure or the previous value of the signal handler.

Example 1: Illustrating the hangup of the signal using the below command

Syntax:

kill -signal  pid

Script:

#!/bin/bash
kill -1  500

Output: 

Explanation:

The signal is the name or number of the signal that has to be given in the kill command syntax above, and pid is the ID of the process to which the signal needs to be sent. The program executing with the 500 process ID receives the signal called hang-up, or HUP, from the aforementioned command. If no such process is running with pid 500 then a message will be displayed as shown in the above output.

Example 2: Illustrating the killing of signal using the below command

Script:

#!/bin/bash
kill -9  500

Output:

Explanation:

Use the above command to send the kill signal to a similar process. The process running under process ID 500 will be terminated by the command already mentioned. If no such process is running with pid 500 then a message will be displayed as shown in the above output.

Conclusion:

There is a default response for each signal. The action that a script or program executes in response to a signal is known as the default action for a signal. For example- stop the procedure, disregard the signal, stop the operation, carry on a halted procedure, etc.