This is caused by the server being first in Master,Down state after which it is put into Maintenance, Down state. Servers in Maintenance state are never monitored but the state change function mistakenly confused the change from non-Maintenance to Maintenance as a state change.

This can be fixed by ignoring any state changes that involve the server being in Maintenance mode. This means that the next change after the maintenance state is cleared, i.e. from Maintenance to non-Maintenance, will not cause a change event.

With this fix, no scripts are executed for servers that either go into or leave Maintenance mode.

I think most desirable behaviour would be if setting and clearing maintenance mode itself triggers the script but any subsequent state changes when the server is in maintenance mode not.

Or are we saying the same thing here?

I don't know if it really makes perfect sense in every situation to trigger the script if a server goes into or out of maintenance. For example the script in MXS-847 puts the server that failed into maintenance which would cause the script to be triggered twice.

Perhaps a new event type would best server this purpose, something like server_maintenance and lost_maintenance. These new events would only be triggered when a server enters or leaves maintenace.

The fix for this bug is simple. Just add a check whether the server was or is going into maintenance, and if so, ignore it.

The improvement where this state change would trigger a new_maintenance or lost_maintenance event requires minor refactoring of the monitor modules.