ctdb-scripts: Lock debugging should print kernel stack for process in D state

Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Michael Adam <obnox@samba.org>

diff --git a/ctdb/config/debug_locks.sh b/ctdb/config/debug_locks.sh
index 3b66b6ae4fc1a42164abce1adbb528f0c2bd5261..8e337518aff5cff449f2aedab95739293a7ae250 100755 (executable)
--- a/ctdb/config/debug_locks.sh
+++ b/ctdb/config/debug_locks.sh
@@ -2,7 +2,7 @@
 
 # This script parses /proc/locks and finds the processes that are holding
 # locks on CTDB databases.  For all those processes the script dumps a
-# stack trace using gstack.
+# stack trace.
 #
 # This script can be used only if Samba is configured to use fcntl locks
 # rather than mutex locks.
@@ -56,8 +56,23 @@ loadconfig ctdb
        # For each process waiting, log stack trace
        for pid in $pids ; do
            echo "----- Stack trace for PID=$pid -----"
-           gstack $pid
-           # gcore -o /var/log/core-deadlock-ctdb $pid
+           read x x state x </proc/$pid/stat
+           if [ "$state" = "D" ] ; then
+               # Don't run gstack on a process in D state since
+               # gstack will hang until the process exits D state.
+               # Although it is possible for a process to transition
+               # to D state after this check, it is unlikely because
+               # if a process is stuck in D state then it is probably
+               # the reason why this script was called.  Note that a
+               # kernel stack almost certainly won't help diagnose a
+               # deadlock... but it will probably give us someone to
+               # blame!
+               echo "----- Process in D state, printing kernel stack only"
+               cat /proc/$pid/stack
+           else
+               gstack $pid
+               # gcore -o /var/log/core-deadlock-ctdb $pid
+           fi
        done
     fi