<delurk>
Rehi gang!
Tossed the latest version of 2.6.0's monitoring core up on one of our shiny
new dual Opterons and it apparently only responds if debug_level is set
nonzero. Doesn't seem to matter whether it's 1 or 10 or 90.
Doesn't seem to matter whether there's a config file present, either.
So I tried it on my P4 desktop and it does the same thing.
It appears that gmond never binds to the port (I'm getting "Connection
refused," and gmond's "untrusted host found" behavior is to accept but then
close the connection).
Before I bust out the debugger, the Sawz-All and the liquid nitrogen, I
thought I would post here and ask if anyone's run into this either during
development or deployment. I seem to remember seeing crazy stuff like this
earlier on in development.
Here are the systems I've tried this on:
* Dual-proc Opteron running heavily-modified Redhat 7.2 with a 2.4.26 kernel.
* Uni-proc P4 running slightly-less-modified Redhat 7.2 with a 2.4.20 kernel.
The Opteron has two on-board copper Gig-E ports, the P4 has one on-board FE
port. I don't think gmond's getting confused about the network. 2.5.6 runs
like a champ on both.
Tried building with gcc 2.9.6 and 3.3.2. Note that the problem pops up on
both platforms. I am thinking along the lines of weird network or daemon code
changes introduced somewhere in the road to 2.6.0.
2.6.0 looks good so far, I just wish I could run it daemonized. :D
</delurk>
