Change Details

The controller currently uses the timeout configured in the `op` element for the recurring monitor (or the default if none) when sending the initial recurring monitor to the executor. The executor uses `pcmk_monitor_timeout`, and if that's longer than what the controller is using, the controller can consider it timed out too early, before the executor replies. See: * [[https://issues.redhat.com/browse/RHEL-14826 | RHEL-14826]]

The controller currently uses the timeout configured in the `op` element for the recurring monitor (or the default if none) when sending the initial recurring monitor to the executor. The executor uses `pcmk_monitor_timeout`, and if that's longer than what the controller is using, the controller can consider it timed out too early, before the executor replies. This would be a good time to update the documentation of fencing timeouts along the lines of [[https://github.com/ClusterLabs/pacemaker/pull/2107 | CLPR#2107]]. See also: * [[https://issues.redhat.com/browse/RHEL-14826 | RHEL-14826]]

The controller currently uses the timeout configured in the `op` element for the recurring monitor (or the default if none) when sending the initial recurring monitor to the executor. The executor uses `pcmk_monitor_timeout`, and if that's longer than what the controller is using, the controller can consider it timed out too early, before the executor replies. SeeThis would be a good time to update the documentation of fencing timeouts along the lines of [[https://github.com/ClusterLabs/pacemaker/pull/2107 | CLPR#2107]]. See also: * [[https://issues.redhat.com/browse/RHEL-14826 | RHEL-14826]]