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)

diff --git a/ctdb/server/ctdb_recover.c b/ctdb/server/ctdb_recover.c
index 85ca2f0dcce227ed020b9413c1ec496d8489e73d..95a684f55efd379e3ecf3b6abe56bc509feabbe3 100644 (file)
--- 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;