All about Linux signals
Table of Contents:
- All about Linux signals
- Introduction
- What is signaled, signal handlers
- Handling specific signals: SIGCHLD, SIGBUS, SIGSEGV, SIGABRT
- What happens when a process receives a signal, system call interruption
- Blocking signals
- Waiting for a signal
- Sending signals
- Real-time signals
- Signals and fork()
- Signals and threads
- Other uses of signals
- That's not everything!
Waiting for a signal
Suppose we want to execute an external command and wait until it exits. We don't want to wait forever, we want to set some timeout after which we will kill the child process. How to do this? To run a command we use fork(2) and execve(2). To wait for a specific process to exit we can use the waitpid(2) function, but it has no timeout parameter. We can also create a loop in which we call sleep(3) with the timeout as an argument and use the fact that sleep(3) will be interrupted by the
SIGCHLD signal. This solution will work... almost. It would contain a race condition: if the process exits immediately, before we call sleep(3) we will wait until the timeout expires. It's a race similar to the one described previously.
The proper solution is to use a dedicated function to wait for a signal: see an example of using sigtimedwait().
This program creates a child process that sleeps few seconds (in a real world application this process would do something like execve(2)) and waits for it to finish. We want to implement a timeout after which the process is killed. The waitpid(2) function does not have a timeout parameter, but we use the SIGCHLD signal that is sent when the child process exits. One solution would be to have a handler for this signal and a loop with sleep(3) in it. The sleep(3) will be interrupted by the SIGCHLD signal or will sleep for the whole time which means the timeout occurred. Such a loop would have a race because the signal could arrive not in the sleep(3), but somewhere else like just before the sleep(3). To solve this we use the sigtimedwait(2) function that allows us to wait for a signal without any race. We can do this because we block the SIGCHLD signal before fork(2) and then call sigtimedwait(2) which atomically unblock the signal and wait for it. If the signal arrives it block it again and returns. It can also take a timeout parameter so it will not sleep forever. So without any trick we can wait for the signal safely.
One drawback is that if sigtimedwait(2) is interrupted by another signal it returns with an error and doesn't tell us how much time elapsed, so we don't know how to properly restart it. The proper solution is to wait for all signals we expect at this point in hte program or block other signals. There is another small bug i the program: when we kill the process, SIGCHLD is sent and we don't handle it anywhere. We should unblock the signal before waitpid(2) and have a handler for it.
Other functions to wait for a signal
There are also other functions that can be used to wait for a signal:
- sigsuspend(2) - waits for any signal. It takes a signal mask of signals that are atomically unblocked, co it doesn't introduce race conditions.
- sigwaitinfo(2) - like sigtimedwait(2), but without the timeout parameter.
- pause(2) - simple function taking no argument. Just waits for any signal. Don't use it, you will introduce a race condition similar to the described previously, use sigsuspend(2).


Hi, typo jerk here
Thanks. I don't consider it
I was looking for linux
Great write-up
Signals - That's not everything