What "fatal" signals should be triggered by a user-level program?

Question

First of all, I know that in the past there was a similar question .

But this question was not answered properly. Instead, he deviated from the suggestion of what to do in order to catch the signals.

So, just to clarify: I did everything I needed to process the signals. I have an application that deploys a daemon that controls the main process through a channel. If the main process fails (for example, a segmentation error), it has a signal handler that writes all the necessary information to the channel and interrupts.

The goal is to have as much information as possible when something bad happens to the application without using a “normal” operation such as SIGHUP, SIGUSR1, etc.

So my question is: what signals should I catch? I mean signals that I will not catch them, since the application will stop interrupting.

So far I have come up with the following list:

• SIGINT (^ C, user initiated, but still good to know)
• SIGTERM ( kill <pid> from the shell or, AFAIK, may be the result of OutOfMemory)
• Sigsegv
• Sigill
• Sigfpe
• Sigbus
• SIGQUIT

Does anyone know if I miss something? kill -l has many of them ... :)

Answer 1

I am looking at my copy of unix advanced programming environment (Stevens). According to the table in the section on signals, the following POSIX signals terminate the process by default if you do not catch them. It would be unwise to keep track of everything you are not using:

• SIGABRT
• SIGALRM
• Sigfpe
• Sighup
• Sigill
• Sigint
• Sigkill
• Sigpipe
• SIGQUIT
• Sigsegv
• Sigterm
• SIGUSR1
• SIGUSR2

You can catch it all except SIGKILL, but hopefully SIGKILL will not appear often for you.

Please note that your signal management page ( man 7 signal ) should provide you with the correct list for your system - this is a POSIX list and may vary depending on your architecture.

Answer 2

You do not have to pick up the signal and write the code into the pipe. This is optional and not safe.

Let me quote the answer to the question you contacted to indicate why it does not work faultlessly: “What makes you think that SEGV has not ruined your program memory yet”

Now you may be wondering how to do it better, and why I said that it is "superfluous".

The return code in syscall waitpid can be checked with WIFSIGNALED() to determine if the process was completed normally or through a signal, and WTERMSIG() will return the signal number.

It is fault tolerant and does not require a processor or pipe. In addition, you do not need to worry about what to catch, because it will report every signal that completes your process.

Answer 3

It depends on what signal you like if it is useful to inform the user that something bad has happened. However, SIGKILL and SIGSTOP cannot be caught.