Todd Finney wrote: [...]
Allow me to rephrase the question. Looking at contemporaneous VMonitor and ExtendedStatus reports (below), I don't know where to being interpreting the differences between the two, or the fact that the spurious processes show up in the former, but not the latter.
In the VMonitor listing, #11 and #16 are both supervise (daemontools) processes. Neither one of them appears in the ExtendedStatus listing, though. If VMonitor is getting its information from the scoreboard, and ExtendedStatus isn't seeing them, where are they coming from?
VMonitor also isn't reporting any activity on children >13, whereas ExtendedStatus is showing that they're in use.
Any chance you could compare the logic of mod_status and Apache::VMonitor and see why there is a difference? In order for me to debug that I need to be able to reproduce the problem. But it seems just fine (and it was like that for a quite a few years). I'd suspect that what you see is some process IDs that used to be use by Apache but now re-used by the OS, and the scoreboard gives the stale info. I see that mod_status has all kind of freshness checks. May be Apache::VMonitor should do the same?
One other question - In the VMonitor source, you have vhost information disabled, and a comment that it's not available in the 1.3 scoreboard. ExtendedStatus is reporting it, though. Where is it getting it from, and why can't VMonitor get to it.
I've just released Apache::Scoreboard 0.12 which exposes the vhost record for mod_perl 1, and the newly released Apache::VMonitor 2.02 uses that information.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
