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").
8 First, we need to get the pid and the full path of the server (e.g. fileserver):
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}'`
14 Then we need to attach the gdb and make it display the stack of all threads :
16 gdb --batch --eval-command="thread apply all where" $SRV_PATH $PID > /tmp/threads.log
18 After this you might use the attached script [[threadLogParser.py]] to display the intersting threads.
22 threadLogParser.py -g /tmp/threads.log -e rx_GetCall
24 displays only threads which are not in this boring rx_GetCall (threads are waiting for a new call).
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".
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.
36 In case of an external-event (the existence of a predefined file), it saves this log and does not overwrite
38 Thus, all you need to do is to write a script which creates this predefined file, when that event happens.