Bedrock currently ignores the proscribed behavior of most of the signals defined
in:
POSIX.1-1990
POSIX.1-2001
4.2BSD
4.4BSD
SVr4
Sys V
There are five basic actions defined for signal handling as per the POSIX
programmers manual:
T Abnormal termination of the process.
A Abnormal termination of the process with additional actions.
I Ignore the signal.
S Stop the process.
C Continue the process, if it is stopped; otherwise, ignore the signal.
The effects on the process in each case are described in the System Interfaces
volume of POSIX.1‐2008, Section 2.4.3, Signal Actions.
Additionally, the signals defined as per the POSIX programmers manual are as
follows:
The ISO C standard only requires the signal names SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM to be defined.
The following signals shall be supported on all implementations (default actions are explained below the table):
┌──────────┬────────────────┬────────────────────────────────────────────────────┐
│ Signal │ Default Action │ Description │
├──────────┼────────────────┼────────────────────────────────────────────────────┤
│SIGABRT │ A │ Process abort signal. │
│SIGALRM │ T │ Alarm clock. │
│SIGBUS │ A │ Access to an undefined portion of a memory object. │
│SIGCHLD │ I │ Child process terminated, stopped, │
│ │ │ or continued. │
│SIGCONT │ C │ Continue executing, if stopped. │
│SIGFPE │ A │ Erroneous arithmetic operation. │
│SIGHUP │ T │ Hangup. │
│SIGILL │ A │ Illegal instruction. │
│SIGINT │ T │ Terminal interrupt signal. │
│SIGKILL │ T │ Kill (cannot be caught or ignored). │
│SIGPIPE │ T │ Write on a pipe with no one to read it. │
│SIGQUIT │ A │ Terminal quit signal. │
│SIGSEGV │ A │ Invalid memory reference. │
│SIGSTOP │ S │ Stop executing (cannot be caught or ignored). │
│SIGTERM │ T │ Termination signal. │
│SIGTSTP │ S │ Terminal stop signal. │
│SIGTTIN │ S │ Background process attempting read. │
│SIGTTOU │ S │ Background process attempting write. │
│SIGUSR1 │ T │ User-defined signal 1. │
│SIGUSR2 │ T │ User-defined signal 2. │
│SIGPOLL │ T │ Pollable event. │
│SIGPROF │ T │ Profiling timer expired. │
│SIGSYS │ A │ Bad system call. │
│SIGTRAP │ A │ Trace/breakpoint trap. │
│SIGURG │ I │ High bandwidth data is available at a socket. │
│SIGVTALRM │ T │ Virtual timer expired. │
│SIGXCPU │ A │ CPU time limit exceeded. │
│SIGXFSZ │ A │ File size limit exceeded. │
│ │ │ │
└──────────┴────────────────┴────────────────────────────────────────────────────┘
Currently Bedrock's behavior is to only watch for the following signals:
- SIGQUIT
- SIGTTIN
- SIGTTOU
- SIGUSR2
In the event of any other signal it will exit as per BedrockServer.cpp#L495:
// For anything else, just shutdown -- but only if we're not already shutting down
This means that if the system is attempting to notify the host of a change in
window size (SIGWINCH
), the system will exit. While it is the prerogative of
Bedrock to decide how to respond to signals, it seems naive to quit on signals
which the Linux man pages (man 7 signal
) proscribe a default behavior of
"ignore" (as is the case of SIGCONT
).
In testing, I confirmed that Bedrock exited in all of the following cases:
(BedrockServer.cpp:506) postSelect [main] [info] Beginning graceful shutdown due
to 'SIGCONT, (unknown#50)', closing command port on 'localhost:8888'
(BedrockServer.cpp:506) postSelect [main] [info] Beginning graceful shutdown due
to 'SIGINT, (unknown#34)', closing command port on 'localhost:8888'
(BedrockServer.cpp:506) postSelect [main] [info] Beginning graceful shutdown due
to 'SIGURG, (unknown#55)', closing command port on 'localhost:8888'
(BedrockServer.cpp:506) postSelect [main] [info] Beginning graceful shutdown due
to 'SIGUSR1, (unknown#42)', closing command port on 'localhost:8888'
(BedrockServer.cpp:506) postSelect [main] [info] Beginning graceful shutdown due
to 'SIGWINCH, (unknown#60)', closing command port on 'localhost:8888'
This was discovered while running Bedrock conncurrently with a piece of software
containing a memory leak which, during page swapping, issued SIGWINCH
.
This issue also raises concerns about the ability to trigger a core dump for
analysis of a running system.