From a9444eb0607eca07a1322a1874015bc193bdd614 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20Pokorn=C3=BD?= Date: Wed, 29 Aug 2018 15:50:57 +0200 Subject: [PATCH] High: stonith-ng's function cannot be blocked with CIB updates forever In the high-load (or high-rate-config-change) scenarios, pacemaker-fenced would be unable to provide service when basically DoS'd with CIB update notifications. Try to reconcile that with elevated priority of the server's proper listening interface in the mainloop, at worst, it will try to fence with slightly outdated config, but appears to be less bad than not carrying the execution at all, for instance. Other daemons might be considered as well. Prerequisites: - https://github.com/ClusterLabs/libqb/pull/352 (libqb used to contain a bug due to which one particular step in the initial-client-connection-accepting-at-the-server procedure that would be carried out with hard-coded (and hence possibly lower than competing events') priority, which backfires exactly in this case (once the pacemaker part is fixed -- by the means of elevating priority for the API end-point of fenced so that it won't get consistently overridden with a non-socket-based event source/trigger) How to verify: - mocked/based -N (see commit adding that module to mocked based daemon) --- lib/common/utils.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/common/utils.c b/lib/common/utils.c index f3f60ed58fe..b87454e7014 100644 --- a/lib/common/utils.c +++ b/lib/common/utils.c @@ -1223,7 +1223,8 @@ attrd_ipc_server_init(qb_ipcs_service_t **ipcs, struct qb_ipcs_service_handlers void stonith_ipc_server_init(qb_ipcs_service_t **ipcs, struct qb_ipcs_service_handlers *cb) { - *ipcs = mainloop_add_ipc_server("stonith-ng", QB_IPC_NATIVE, cb); + *ipcs = mainloop_add_ipc_server_with_prio("stonith-ng", QB_IPC_NATIVE, cb, + QB_LOOP_HIGH); if (*ipcs == NULL) { crm_err("Failed to create stonith-ng servers: exiting and inhibiting respawn.");