RFC: Signal Service for OS Signals

[psyeugenic]

In todays Erlang runtime system OS signals cannot be handled by an Erlang developer. Some signals are used internally by erts, for instance

• SIGUSR1 is used to generate crashdumps,
• SIGUSR2 is used to halt threads in a crashdump,
• SIGQUIT is used to halt Erlang immediately,
• SIGINT is used for a break-handler which is only intended to be used for debugging and
• SIGTERM (from 19.3) will halt Erlang via init:stop/0.

With this PR a gen_event server, erl_signal_server, is started to handle enabled signals from the operating system. A default handler is installed to mimic the previous behavior of above signals except for SIGINT. The break-handler still uses SIGINT internally.

Subscribable signals with this PR are: SIGHUP, SIGILL, SIGABRT, SIGALRM, SIGTERM, SIGQUIT, SIGUSR1, SIGUSR2, SIGCHLD, SIGSTOP, SIGTSTP.

Signals can be enabled with erts_internal:set_signal(Signal, Option), where Signal is any subscribable signal, i.e. sighup or sigusr1, and Option is one of handle, ignore or default. By setting handle for a signal it means that a notification will be sent to erl_signal_server once that signal has been received from the OS.

Names are up for debate of course. As is the usability of this feature. SIGTERM and SIGHUP was the initial driving force for this.

[bjorng]

I don't think that it should be allowed to handle SIGILL. There is no way to predict the state of the run-time system after executing an illegal instruction. Attempting to handle may do more harm than good, and could make it harder to find the original problem.

Not sure about SIGCHLD either. Couldn't handling it interfere with open_port({spawn,...}, ...) or cause zombie processes?

[psyeugenic]

@bjorng I agree that SIGILL may not be that useful however SIGCHLD may be useful in some instances. It could perhaps be useful when running beam as PID 1 to mitigate the zombie problem. At least there would be a way to handle SIGCHLD signals. There is no interference with port programs today since those SIGCHLDs are sent to the forker process and not the beam process. I can't see that we have a zombie problem there. Also, in the testcase os_signal_SUITE:t_sigchld_fork/1 we test for fork() and waitpid(). No zombies - in that testcase either.

Once again, I agree that SIGILL should probably be removed. Are there any other modifications to the signal whitelist that should be done?

[psyeugenic]

Changed module from erts_internal to os since it's more appropriate.

There is a coupling here that needs to be reconsidered. If a signal is set to be handled it will always send notifications to erl_signal_server. Viewing the kernel application as a part of the runtime this would be fine but I think I would rather decouple this an additional step.

[mikpe]

For Erlang code it only makes sense to allow asynchronous signals to be handled. Synchronous ones corresponding to hardware traps (SIGILL, SIGBUS, SIGSEGV, SIGFPE) should be excluded.

[skull-squadron]

      handleable ignorable 
KILL       n         n 
STOP       n         n
CONT       y         n

References:

• https://www.gnu.org/software/libc/manual/html_node/Standard-Signals.html#Standard-Signals
• https://www.gnu.org/software/coreutils/manual/html_node/Signal-specifications.html
• http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html