From b3ff7d904d17b8deda23605a38f0add99bade6c4 Mon Sep 17 00:00:00 2001 From: Ronnie Sahlberg Date: Tue, 16 Oct 2007 09:50:31 +1000 Subject: [PATCH] dont try to lock the file from inside the ctdb daemon. eventhough we dont want a blocking lock it does appear that the fcntl() call can block for a while if gpfs is in the process of rebuilding itself after a node arriving/leaving the cluster (This used to be ctdb commit 6c0d206dea7116db71bccb4802a93dd7283249f6) --- ctdb/server/ctdb_recover.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/ctdb/server/ctdb_recover.c b/ctdb/server/ctdb_recover.c index 85ca2f0dcce..95a684f55ef 100644 --- a/ctdb/server/ctdb_recover.c +++ b/ctdb/server/ctdb_recover.c @@ -451,14 +451,6 @@ int32_t ctdb_control_set_recmode(struct ctdb_context *ctdb, state = talloc(ctdb, struct ctdb_set_recmode_state); CTDB_NO_MEMORY(ctdb, state); - /* we should not be able to get the lock on the nodes list, as it should be - held by the recovery master */ - if (ctdb_recovery_lock(ctdb, false)) { - DEBUG(0,("ERROR: recovery lock file %s not locked when recovering!\n", - ctdb->recovery_lock_file)); - return -1; - } - state->c = talloc_steal(state, c); state->recmode = recmode; -- 2.47.3