ctdb-scripts: Don't bother checking PID file when starting ctdbd

This is an optimisation that can cause incorrect results.  If ctdbd
was killed and there is a stale PID file then this will often cause
"CTDB exited during initialisation".  The wrapper reads the old PID
from the PID file, finds the PID gone, complains and exits.

It is better to drop this code and finally get this right.  If ctdbd
does exit early then it will take CTDB_STARTUP_TIMEOUT (default 10)
seconds before the wrapper fails.  That's not too bad...

Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>

1 files changed, 2 insertions, 16 deletions

diff --git a/ctdb/config/ctdbd_wrapper b/ctdb/config/ctdbd_wrapper
index 8a9f554dd5f..8eec379910e 100755
--- a/ctdb/config/ctdbd_wrapper
+++ b/ctdb/config/ctdbd_wrapper
@@ -227,22 +227,8 @@ start()
     _timeout="${CTDB_STARTUP_TIMEOUT:-10}"
     _count=0
     while [ "$_count" -lt "$_timeout" ] ; do
-	# If we don't have the PID then try to read it.
-	[ -n "$_pid" ] || read _pid 2>/dev/null <"$pidfile"
-
-	# If we got the PID but the PID file has gone or the process
-	# is no longer running then stop waiting... CTDB is dead.
-	if [ -n "$_pid" ] ; then
-	    if [ ! -e "$pidfile" ] || ! kill -0 "$_pid" 2>/dev/null ; then
-		echo "CTDB exited during initialisation - check logs."
-		kill_ctdbd "$_pid"
-		drop_all_public_ips >/dev/null 2>&1
-		return 1
-	    fi
-
-	    if $CTDB runstate first_recovery startup running >/dev/null 2>&1 ; then
-		return 0
-	    fi
+	if $CTDB runstate first_recovery startup running >/dev/null 2>&1 ; then
+	    return 0
 	fi
 
 	_count=$((_count + 1))