Other uses of signals

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....

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:...

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....

Signal Handler

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

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....

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....