What happens when a process receives a signal?

Default actions

• Termination of a process. This is the most common action. Not only for SIGTERM or SIGQUIT but also for signals like SIGPIPE, SIGUSR1, SIGUSR2 and others.
• Termination with code dump. This is common for signals that indicate a bug in the program like SIGSEGV, SIGILL, SIGABRT and others.
• Few signals are ignored by default like SIGCHLD.
• SIGSTOP (and similar stop signals) cause the program to suspend and SIGCOND to continue. The most common situation is when you use the CTRL-Z command in the shell.

For a complete list of default actions see the signal(7) manual page.

Interrupting system calls

What is interrupted?

Simple example of signal aware code

#include <unistd.h>
#include <signal.h>
 
static void hdl (int sig)
{
}
 
void my_sleep (int seconds)
{
        while (seconds > 0)
                seconds = sleep (seconds);
}
 
int main (int argc, char *argv[])
{
        signal (SIGTERM, hdl);
 
        my_sleep (10);
 
        return 0;
}

This example works, but if you try it and send few signals during sleep you can see that it may sleep different amount of time. This is because sleep(3) takes the argument and returns the value with 1s resolution so it can't be precise telling you how long it need to sleep after interruption.

Data transferring and signals

See an example of how to handle interruption of system calls.

This program reads from it's standard input and copies the data to the standard output. Additionally, when SIGUSR1 is received it prints to stderr how many bytes has been already read and written. It installs a signal handler which sets a global flag to 1 if called. Whatever the program does at the moment it receives the signal, the numbers are immediately printed. It works because read(2) and write(2) functions are interrupted by signals even during operation. In case of those functions two things might happen:

• When read(2) waits for data or write(2) waits for stdout to put some data and no data were yet transfered in the call and SIGUSR1 arrives those functions exit with return value of -1. You can distinguish this situation from other errors by reading the value of the errno variable. If it's EINTR it means that the function was interrupted without any data transfered and we can call the function again with the same parameters.
• Another case is that some data were transfered but the function was interrupted before it finished. In this case the functions don't return an error but a value less that the supplied data size (or buffer size). Neither the return value nor the errno variable tells us that the function was interrupted by a signal, if we want to distinguish this case we need to set some flag in the signal handler (as we do in this example). To continue after interruption we need to call the function again keeping in mind that some data were consumed or read adn we must restart from the right point. In our example only the write(2) must be properly restarted, we use the written variable to track how many bytes were actually written and properly call write(2) again if there are data left in the buffer.

Remember that not all system calls behave exactly the same way, consult their manual page to make sure.

Reading the sigaction(2) manual page you can think that setting the SA_RESTART flag is simpler that handling system call interruption. The documentation says that setting it will make certain system calls automatically restartable across signals. It's not specified which calls are restarted. This flag is mainly used for compatibility with older systems, don't use it.