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>

diff --git a/ctdb/config/ctdbd_wrapper b/ctdb/config/ctdbd_wrapper
index 8a9f554dd5f1854e3b2ff4bf8437a7799fb1026b..8eec379910ef94da2845a5c49b0924b432589a53 100755 (executable)
--- 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))