Wiki Navigation

← Previous Change
Page History
Next Change →

Changes between Version 4 and Version 5 of ServerDebug

Author:: davea (IP: 128.32.18.181)
Timestamp:: 06/16/09 13:07:01 (5 months ago)
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

ServerDebug

v4	v5
5	5	== Log files ==
6	6
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` (where 12345 represents the ID) in the log files. The [HtmlOps html/ops pages] also provide an interface for this.
	7	Each server component (scheduler, feeder, transitioner, etc.) has its own log file.
	8	Most error conditions are reported in the log files;
	9	make sure you know where they are.
	10	If you're interested in the history of a particular WU or result,
	11	grep for `WU#12345` or `RESULT#12345` (where 12345 represents the ID) in the log files.
	12	The [HtmlOps html/ops pages] also provide an interface for this.
	13
	14	To control the verbosity of the log files:
	15
	16	* Scheduler: set the desired [ProjectOptions#Scheduler:logging logging options]
	17	* File upload handler: set [ProjectOptions#misc fuh_debug_level].
	18	* Other components: pass "-d N" (1=least verbose, 3=most verbose)
8	19
9	20	== Debugging the scheduler ==
10	21
	22	Start by setting the appropriate logging options and examining the log file.
	23
	24	If this doesn't reveal the problem, or if the scheduler is crashing,
	25	you can run it under a debugger like `gdb`.
11	26	The scheduler is a CGI program;
12	27	it reads a request from stdin and writes a reply to stdout.
13		You can run it with a command-line debugger like `gdb`:
	28	So you can debug it as follows:
	29
14	30	* Copy the "scheduler_request_X.xml" file from a client to the machine running the scheduler. (X = your project URL)
15	31	* Run the scheduler under the debugger, giving it this file as stdin, i.e.:
24	40	}}}
25	41
26		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.
	42	This is useful for figuring out why your project is generating 'no work available' messages.
	43	As an alternative to this, edit `handle_request.C`,
	44	and put a call to `debug_sched(sreq, sreply, "../debug_sched")` just before `sreply.write(fout)`.
	45	Then, after recompiling, touch a file called 'debug_sched' in the project root directory.
	46	This will cause transcripts of all subsequent scheduler requests and replies
	47	to be written to the `cgi-bin/` directory with separate small files for each request.
	48	The file names are `sched_request_H_R` where H=hostid and R=rpc sequence number.
	49	This can be turned off by deleting the 'debug_sched' file.
27	50
28	51	To get core files for scheduler crashes, put the following line in sched/main.C, and recompile:

If this page is incomplete or incorrect, please edit it or add it to the wiki to-do list. To do this, you must be logged in; click Login or Register above.