The shutdown signal handlers were installed before the workers were
initialized and weren't removed before the workers were deleted. This
would lead to a debug assertion and an eventual crash when a SIGTERM
signal was received outside of the expected scope.
The proper way to do this is to install the handlers only after the system
is up and running and to disable them as soon as the shutdown process
starts.
This mostly happened with the mxs621_unreadable_cnf test as it seemed to
receive a SIGTERM during the execution of the at-exit handlers.
As long as the same thread never handles more than one fatal signal,
multiple fatal signals can be processed. This should guarantee that the
stacktrace is printed into the log while guaranteeing that recursion never
takes place if the handling of a fatal signal causes a fatal signal to be
emitted.
As long as the same thread never handles more than one fatal signal,
multiple fatal signals can be processed. This should guarantee that the
stacktrace is printed into the log while guaranteeing that recursion never
takes place if the handling of a fatal signal causes a fatal signal to be
emitted.
By printing the stacktrace in one log message, it prevents it from
interleaving with other messages. This happens on busy systems and makes
crash analysis harder.
Now properly checks if configuration and diagnostics functions are ran in either
main() or in the admin worker. This is useful for debugging and enforcing
thread safety.
Also, monitors are now started and stopped in the admin worker.
By stopping the REST API before the workers and moving the shutdown to the
same worker that handles REST API requests, we prevent the hang on
shutdown. This also makes the signal handler signal-safe.
The class MonitorManager contains monitor-related functions that should not
be called from modules. MonitorManager can access private fields and methods
of the monitor.
