Question

This is regarding the application that runs on POSIX (Linux) environment. Most signals (e.g. Ctrl+C – signal 2, SIGINT), and few others are handled. When that is done the exit() system call is called from the handler with a desirable exit code.

However, there are some signals like Signal 9 and Signal 15 can’t be handled.

Unfortunately, the parent process (an external script) which launches the given application needs to know and clean up some stuff if the signal 9 or 15 was the reason for termination.

Is there a predefined exit code that can be received by parent process to know the above?

The script that launches the app is a bash_script. The application itself is in C.

Answer 1

The return status from wait() or waitpid() encodes the information you need.

The POSIX macros are:

• WIFEXITED(status) returns true if the child exited via exit() or one of its relatives.
• WEXITSTATUS(status) tells you what that exit status was (0..255).
• WIFSIGNALED(status) returns true if the child exited because of a signal (any signal).
• WTERMSIG(status) returns the signal number that killed the child.

The non-standard but common macro WCOREDUMP(status) tells you if the process dumped core. You can also tell whether status reflect that the process was stopped, or continued (and what the stop signal was).

Note that signal 15 is usually SIGTERM and SIGTERM can be trapped by an application. The signals that cannot be trapped are SIGKILL (9) and SIGSTOP (17 on Mac OS X; may not be the same everywhere).

---

The question then is if bash provides this info for a script.

The answer is yes, but only indirectly and not 100% unambiguously. The status value reported by bash will be 128 + <signum> for processes that terminate due to signal <signum>, but you can’t distinguish between a process that exits with status 130, say, and a process that was interrupted by SIGINT, aka signal 2.