(no commit message)

diff --git a/AFSLore/debugging.mdwn b/AFSLore/debugging.mdwn
new file mode 100644 (file)
index 0000000..9b34287
--- /dev/null
+++ b/AFSLore/debugging.mdwn
@@ -0,0 +1,39 @@
+## Debugging Servers
+
+Servers are multithreaded, so if one hangs, it is most interesting to see<br/>
+what the different threads are doing. <br/>
+Using gdb, you can get a stack trace of all threads <br/>
+(provided, you compiled your server with "--enable-debug").
+
+First, we need to get the pid and the full path of the server (e.g. fileserver):
+
+    PID=`ps -eaf | grep fileserver | grep -v grep | awk '{print $2}'`
+    SRV_PATH=`ps -eaf | grep fileserver | grep -v grep | awk '{print $9}'`
+
+
+Then we need to attach the gdb and make it display the stack of all threads :
+    
+    gdb --batch --eval-command="thread apply all where" $SRV_PATH $PID > /tmp/threads.log
+
+After this you might use the attached script "threadLogParser.py" to display the intersting threads.
+
+e.g.
+
+    threadLogParser.py -g /tmp/threads.log -e rx_GetCall
+
+displays only threads which are not in this boring rx_GetCall (threads are waiting for a new call).
+
+
+## Debugging Clients
+
+Low-level debugging of a client can be done using "fstrace". <br/>
+Unfortunately, this produces a lot of output, so it is not easy 
+to catch an intermittent error-condition with "fstrace".
+
+The attached script "ClientTracing.py" gives you the opportunity to continuously run a fstrace, <br/>
+where the output is stored in rotating log-files. 
+
+In case of an external-event (the existence of a predefined file), it saves this log and does not overwrite
+it again.<br/>
+Thus, all you need to do is to write a script which creates this predefined file, when that event happens.
+