Interview question: signals

10 years ago

An interrupt is usually generated by the hardware when the processor needs to stop whatever it is doing to deal with some urgent mater. Strangely enough, we also have software interrupts. On unix, we have some high level ones called signals.

One typical interview question is: which signals can't be caught or ignored?

When I was asked this for the first time a long time ago, my answer was... SIGBUS. I thought that there was not much that could be done about a hardware error. I made two mistakes that day.

The first one is brought by the signal (2) man page, that gives the answer the interviewer was surely waiting for: "The signals SIGKILL and SIGSTOP cannot be caught or ignored". signal() and sigaction() will return an error if we try to change their disposition.

But there is more

A couple of years ago, an ex-googler told me that SIGCONT can not be blocked or masked when the process is sleeping.

When reading the very good The linux programming interface from Michael Kerrisk all of this is explained and much more. It turns out that my intuition was not totally wrong. According to the book:

the Single Unix Specification (SUSv3) let undefined what happens when we return from a signal handler for hardware generated signals: SIGBUS, SIGFPE, SIGSEGV and SIGEMT. 

They can't be blocked on modern Linux systems and trying to ignore them will simply terminate those programs.

So when asked about anything...

...don't just answer. Say a bit more about your reasoning. And read books like Michael Kerrisk's one, it's definitely worth the investment. I'll try to post some more about it in a following post.

PS:

• Another oddity about signals a bit later in the book:

[Originally on BSD], a process could be stopped in one of two ways: as a consequence of being traced by the ptrace() system call, or by being stopped by a signal [...]. When a child is being traced by ptrace(), then delivery of any signal (other than SIGKILL) causes the child to be stopped, and a SIGCHLD signal is consequently sent to the parent. This behavior occurs even if the child is ignoring the signal. However, if the child is blocking the signal, then it is not stopped.

•  And another one, this time from the abort() man page. [when calling abort()], if the SIGABRT signal is ignored, or caught by a handler that returns, the abort() function will still terminate the process. It does this by restoring the default disposition for SIGABRT and then raising the signal for a second time.