Changes between Version 4 and Version 5 of ServerDebug

Timestamp:

Jun 16, 2009, 1:07:01 PM (15 years ago)

Author:

davea

Comment:

--

ServerDebug

@@ -5 +5 @@
 == Log files ==
 
-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` (where 12345 represents the ID) in the log files. The [HtmlOps html/ops pages] also provide an interface for this.
+Each server component (scheduler, feeder, transitioner, etc.) has its own log file.
+Most error conditions are reported in the log files;
+make sure you know where they are.
+If you're interested in the history of a particular WU or result,
+grep for `WU#12345` or `RESULT#12345` (where 12345 represents the ID) in the log files.
+The [HtmlOps html/ops pages] also provide an interface for this.
+
+To control the verbosity of the log files:
+
+ * Scheduler: set the desired [ProjectOptions#Scheduler:logging logging options]
+ * File upload handler: set [ProjectOptions#misc fuh_debug_level].
+ * Other components: pass "-d N" (1=least verbose, 3=most verbose)
 
 == Debugging the scheduler ==
 
+Start by setting the appropriate logging options and examining the log file.
+
+If this doesn't reveal the problem, or if the scheduler is crashing,
+you can run it under a debugger like `gdb`.
 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`:
+So you can debug it as follows:
+
  * 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.:
@@ -24 +40 @@
 }}}
 
-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.
+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 the following line in sched/main.C, and recompile: