Changes between Version 1 and Version 2 of ServerDebug
- Timestamp:
- Apr 24, 2007, 8:40:18 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ServerDebug
v1 v2 5 5 6 6 == Log files == 7 Most error conditions are reported in the log files. Make sure you know where these are. If you're interested in the history of a particular WU or result, grep for WU#12345 or RESULT#12345 (12345 represents the ID) in the log files. The html/ops pages also provide an interface for this. 7 8 Most error conditions are reported in the log files. Make sure you know where these are. If you're interested in the history of a particular WU or result, grep for WU!#12345 or RESULT!#12345 (12345 represents the ID) in the log files. The html/ops pages also provide an interface for this. 9 8 10 == Database query tracing == 9 If you uncomment the symbol SHOW_QUERIES in db/db_base.C, and recompile everything, all database queries will be written to stderr (for daemons, this goes to log files; for command-line apps it's written to your terminal). This is verbose but extremely useful for tracking down database-level problems. 11 12 If you uncomment the symbol SHOW_QUERIES in db/db_base.C, and recompile everything, all database queries will be written to stderr (for daemons, this goes to log files; for command-line apps it's written to your terminal). This is verbose but extremely useful for tracking down database-level problems. 10 13 == Getting core dumps from the scheduler == 11 In sched/main.C put:12 14 15 In sched/main.C put: 13 16 14 17 {{{ 15 18 #define DUMP_CORE_ON_SEGV 1 16 19 }}} 17 and recompile. 20 and recompile. 21 18 22 == Running the scheduler under a debugger == 19 The scheduler is a CGI program. It reads from stdin and writes to stdout, so you can also run it with a command-line debugger like gdb: 23 24 The scheduler is a CGI program. It reads from stdin and writes to stdout, so you can also run it with a command-line debugger like gdb: 20 25 * Copy the "scheduler_request_X.xml" file from a client to the machine running the scheduler. (X = your project URL) 21 26 * Run the scheduler under the debugger, giving it this file as stdin, i.e.: 22 27 {{{ 23 24 25 28 gdb cgi 29 (set a breakpoint) 30 r < scheduler_request_X.xml 26 31 }}} 27 32 * You may have to doctor the database as follows: 28 33 {{{ 29 30 31 34 update host set rpc_seqno=0, rpc_time=0 where hostid=N 35 }}} 36 to keep the scheduler from rejecting the request. 32 37 33 This is useful for figuring out why your project is generating 'no work available' messages. As an alternative to this, edit handle_request.C, and put a call to debug_sched(sreq, sreply, "../debug_sched") just before sreply.write(fout). Then, after recompiling, touch a file called 'debug_sched' in the project root directory. This will cause transcripts of all subsequent scheduler requests and replies to be written to the cgi-bin/ directory with separate small files for each request. The file names are sched_request_H_R where H=hostid and R=rpc sequence number. This can be turned off by deleting the 'debug_sched' file. 38 This is useful for figuring out why your project is generating 'no work available' messages. As an alternative to this, edit handle_request.C, and put a call to debug_sched(sreq, sreply, "../debug_sched") just before sreply.write(fout). Then, after recompiling, touch a file called 'debug_sched' in the project root directory. This will cause transcripts of all subsequent scheduler requests and replies to be written to the cgi-bin/ directory with separate small files for each request. The file names are sched_request_H_R where H=hostid and R=rpc sequence number. This can be turned off by deleting the 'debug_sched' file. 39 34 40 == MySQL interfaces == 35 You should become familiar with MySQL tools such as 41 42 You should become familiar with MySQL tools such as 36 43 * mytop: like 'top' for MySQL 37 44 * the mysql interpreter ('mysql') and in particular the 'show processlist;' query.
