Problem

In MXS-5187 a SIGABRT was sent due to a potential systemd watchdog timeout. The stacktraces were a bit suspicious so it's theoretically possible for this to be something else.

To be more certain of the source of a SIGABRT, MaxScale should somehow figure out if the SIGABRT relates to a watchdog timeout or something else.

Solutions

Scan systemd journal for messages

This solution would give us with a 100% certainty an answer to the question. The problem with this approach is that due to the problems described in MXS-5196, the messages cannot be read without being a part of the systemd-journal group. This could be added but given that MaxScale usually does not need this (maxlog=1 is the default), it, for the time being, is better left to the end user to choose whether to allow MaxScale to read the log.

Track when the last watchdog notification was sent

The notification interval and the time when the last notification was sent is known by MaxScale. By logging this information in the signal handler, we'd be able to tell with a high likelihood whether the SIGABRT was due to a watchdog timeout simply by looking at when the last notification was sent and how often they should be sent. Since the notifications are sent twice as often as are needed, the difference in times should be very obvious.