rm spam
[openafs-wiki.git] / AFSLore / debugging.mdwn
1 ## Debugging Servers
2
3 Servers are multithreaded, so if one hangs, it is most interesting to see<br/>
4 what the different threads are doing. <br/>
5 Using gdb, you can get a stack trace of all threads <br/>
6 (provided, you compiled your server with "--enable-debug").
7
8 First, we need to get the pid and the full path of the server (e.g. fileserver):
9
10     PID=`ps -eaf | grep fileserver | grep -v grep | awk '{print $2}'`
11     SRV_PATH=`ps -eaf | grep fileserver | grep -v grep | awk '{print $9}'`
12
13
14 Then we need to attach the gdb and make it display the stack of all threads :
15     
16     gdb --batch --eval-command="thread apply all where" $SRV_PATH $PID > /tmp/threads.log
17
18 After this you might use the attached script [[threadLogParser.py]] to display the intersting threads.
19
20 e.g.
21
22     threadLogParser.py -g /tmp/threads.log -e rx_GetCall
23
24 displays only threads which are not in this boring rx_GetCall (threads are waiting for a new call).
25
26
27 ## Debugging Clients
28
29 Low-level debugging of a client can be done using "fstrace". <br/>
30 Unfortunately, this produces a lot of output, so it is not easy 
31 to catch an intermittent error-condition with "fstrace".
32
33 The attached script [[ClientTracing.py]] gives you the opportunity to continuously run a fstrace, <br/>
34 where the output is stored in rotating log-files. 
35
36 In case of an external-event (the existence of a predefined file), it saves this log and does not overwrite
37 it again.
38 Thus, all you need to do is to write a script which creates this predefined file, when that event happens.
39
40