From: Buchan M. <bg...@st...> - 2010-03-11 11:42:42
|
On Thursday, 11 March 2010 08:15:18 Stef Coene wrote: > On Thursday 11 March 2010, Buchan Milne wrote: > > If the problem persists, watch to see if the dm test for the polling > > device goes yellow or red, or polled devices go purple, and provide the > > log contents for at least the last two poll cycles before any of these > > changes (or, the relevant problems). > > For debugging, maybe you can trap a USR signal and dump the internal status > information in the logfile. So when the status turns purple, you can debug > the running process. Let's first see if the problem is fixed or not, and if not if the logging shows (over a period of hours) what happened. Note that the changes to the dm test show enough (IMHO) of what the master knows about the forks. As far as I can tell, the forks end up just waiting for the master to give them something to do, so there would be very little useful information they could give us ... > I also use this myself to force a process to re-read it's config files and > re- open the log files. I've used HUP re-opening log files, config reading is done by running a separate process to populate the db, and the db is read on every poll interval, I don't see much benefit to changing other configuration on a running process. Really, someone who can reproduce this within a regular interval needs to test the current svn version. Regards, Buchan |