Changes between Version 2 and Version 3 of ServerDebug

Timestamp:

Jul 6, 2007, 10:20:10 AM (17 years ago)

Author:

davea

Comment:

--

ServerDebug

@@ -8 +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.
 
-== Database query tracing ==
+== Debugging the scheduler ==
 
-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.
-== Getting core dumps from the scheduler ==
-
-In sched/main.C put:
-
-{{{
-#define DUMP_CORE_ON_SEGV 1
-}}}
-and recompile.
-
-== Running the scheduler under a debugger ==
-
-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:
- * Copy the "scheduler_request_X.xml" file from a client to the    machine running the scheduler.  (X = your project URL)
+The scheduler is a CGI program;
+it reads a request from stdin and writes a reply to stdout.
+You can run it with a command-line debugger like gdb:
+ * Copy the "scheduler_request_X.xml" file from a client to the machine running the scheduler. (X = your project URL)
  * Run the scheduler under the debugger, giving it this file as stdin,    i.e.:
 {{{
@@ -34 +24 @@
 update host set rpc_seqno=0, rpc_time=0 where hostid=N
 }}}
- to keep the scheduler from rejecting the request.
+to keep the scheduler from rejecting the request.
 
 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.
+
+To get core files for scheduler crashes, put
+{{{
+#define DUMP_CORE_ON_SEGV 1
+}}}
+in sched/main.C, and recompile.
 
 == MySQL interfaces ==
@@ -45 +41 @@
  * MySQLadmin: general-purpose web interface to MySQL
 
+== Database query tracing ==
+
+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.
+