Client information not showing up
list Gregor Mosheh
Hi, all. I'm getting the old familiar problem that the client info is not showing up in the report. Ideas? The hostname on the client matches the hostname in the bb-hosts: 208.96.11.149 build64 # ftp ssh https://208.96.11.149:10000/ root at build64:/usr/local/hobbit/client# uname -n build64 Port 1984 on the client is reachable from the server: # telnet 208.96.11.149 1984 Trying 208.96.11.149... Connected to 208.96.11.149. Escape character is '^]'. The client is running: hobbit 30455 0.0 0.1 2948 464 ? Ss 10:20 0:00 /usr/local/hobbit/client/bin/hobbitlaunch --config=/usr/local/hobbit/client/etc/clientlaunch.cfg --log=/usr/local/hobbit/client/logs/clientlaunch.log --pidfile=/usr/local/hobbit/client/logs/clientlaunch.build64.pid hobbit 30456 0.0 0.2 2692 552 ? S 10:20 0:00 /usr/local/hobbit/client/bin/msgcache --no-daemon --pidfile=/usr/local/hobbit/client/logs/msgcache.pid hobbit 30637 0.0 0.5 5936 1320 ? S 10:40 0:00 sh -c vmstat 300 2 1>/usr/local/hobbit/client/tmp/hobbit_vmstat.build64.30620 2>&1; mv /usr/local/hobbit/client/tmp/hobbit_vmstat.build64.30620 /usr/local/hobbit/client/tmp/hobbit_vmstat.build64 Any other ideas? Is there a way I can manually connect to the client to fetch a status report? Is there a logfile that contains useful error messages? -- HostGIS Cartographic development and hosting services XXX-XXX-XXXX http://www.HostGIS.com/
list Peter Welter
Hi, The client must be able to connect the server on port 1984; not the other way around. Regards, Peter 2006/12/30, Gregor Mosheh <user-e67e137f2f27@xymon.invalid>:
▸
The hostname on the client matches the hostname in the bb-hosts: 208.96.11.149 build64 # ftp ssh https://208.96.11.149:10000/ Port 1984 on the client is reachable from the server: # telnet 208.96.11.149 1984 Trying 208.96.11.149... Connected to 208.96.11.149. Escape character is '^]'.
list Henrik Størner
▸
On Sat, Dec 30, 2006 at 11:37:42AM -0700, Gregor Mosheh wrote:
Hi, all. I'm getting the old familiar problem that the client info is not showing up in the report. Ideas? The hostname on the client matches the hostname in the bb-hosts: 208.96.11.149 build64 # ftp ssh https://208.96.11.149:10000/
You're missing a "pulldata" tag there, so hobbitfetch won't try to contact this client. And of course, make sure you have the "hobbitfetch" task enabled on the Hobbit server. Henrik
list Henrik Størner
▸
On Sat, Dec 30, 2006 at 09:09:10PM +0100, Peter Welter wrote:
The client must be able to connect the server on port 1984; not the other way around.
Except if you're using the hobbitfetch/msgcache utilities to reverse that. Henrik
list Gregor Mosheh
▸
You're missing a "pulldata" tag there, so hobbitfetch won't try to contact this client.
Actually, that was in the .default entry, which I neglected to post. Here are the relevant bb-hosts entries (probably with line wraparound): .default defaultsettings # testip pulldata hobbitd disk cpu memory procs load 208.96.11.148 hosting1.hostgis.com # bbd 208.96.11.149 build64 # ftp ssh https://208.96.11.149:10000/ During my testing, I've also tried moving the contents of the .default line into the individual host entries; this had no effect.
▸
And of course, make sure you have the "hobbitfetch" task enabled on the Hobbit server.
Got that:
[hobbitfetch]
ENVFILE /usr/local/hobbit/server/etc/hobbitserver.cfg
CMD $BBHOME/bin/hobbitfetch --server=208.96.11.148 --no-daemon
--pidfile=$BBSERVERLOGS/hobbitfetch.pid
LOGFILE $BBSERVERLOGS/hobbitfetch.log
# ps aux | grep fetch
hobbit 16165 0.0 0.0 2672 604 ? S 13:19 0:00
/usr/local/hobbit/server/bin/hobbitfetch --server=208.96.11.148
--no-daemon --pidfile=/usr//local/hobbit/log/hobbitfetch.pid
Other information:
A) When I restart the hobbit service and repeatedly do netstat to see
what's going on, I get many entries for it connecting to 208.96.11.148 --
this is the only host for which the tests are working properly. I do not
see any network activity in regards to the build64 host.
B) Not only is it showing "-" for the cpu, proc, etc. services, but the
report page is also showing "-" for the hobbitd service on build64.
According to the above bb-hosts file, the server should be testing for
that service (independently of the individual cpu/proc/mem/etc) and
alerting if it can't get a report, yes?
list Henrik Størner
▸
On Sat, Dec 30, 2006 at 02:22:39PM -0700, Gregor Mosheh wrote:
You're missing a "pulldata" tag there, so hobbitfetch won't try to contact this client.Actually, that was in the .default entry, which I neglected to post. Here are the relevant bb-hosts entries (probably with line wraparound): .default defaultsettings # testip pulldata hobbitd disk cpu memory procs load
"hobbitd", "disk", "cpu", "memory", "procs" and "load" are meaningless here. All of these are local tests and will show up regardless of what you put into bb-hosts, if there are any data to feed thm. And "hobbitd" only appears on the Hobbit *server*, not on any clients.
208.96.11.148 hosting1.hostgis.com # bbd 208.96.11.149 build64 # ftp ssh https://208.96.11.149:10000/
What happens if you run (on the Hobbit server): bb 208.86.11.149 "pullclient" It should dump the contents of the client message to the screen. If it does, check your "Reports"->"Ghost clients" list and see what hostname the client is *really* using when sending data to the Hobbit server; it's also on the first line of that output from the bb command,e.g. it looks like this here: 31552:120 client osiris,hswn,dk.linux linux [date] Sat Dec 30 22:34:31 CET 2006 If no data appears, then the problem is on the client side. Check the logs there for any errors (in ~hobbit/client/logs/). Henrik
list Gregor Mosheh
▸
"hobbitd", "disk", "cpu", "memory", "procs" and "load" are meaningless here. All of these are local tests and will show up regardless of what you put into bb-hosts, if there are any data to feed thm.
Ah, okie doke.
And "hobbitd" only appears on the Hobbit *server*, not on any clients.
Ah, gotcha. I had misread, thought it was to check the hobbitd service on the client. I take it that 'hobbitd' is synonymous with 'bbd' then?
▸
What happens if you run (on the Hobbit server): bb 208.86.11.149 "pullclient"
Absolutely nothing. Hrm. Checking the client's hobbitclient.log, I get lots of "Whoops ! bb failed to send message - timeout" The other logs have nothing interesting; successful startup, etc. Where do I go next to track down the timeout?
list Henrik Størner
▸
On Sat, Dec 30, 2006 at 02:55:56PM -0700, Gregor Mosheh wrote:
And "hobbitd" only appears on the Hobbit *server*, not on any clients.Ah, gotcha. I had misread, thought it was to check the hobbitd service on the client. I take it that 'hobbitd' is synonymous with 'bbd' then?
No, "bbd" checks the Hobbit daemon's network interface. "hobbitd" just provides some statistics about all of Hobbit, and goes red/yellow if any problems are logged to the hobbitd logfiles.
▸
What happens if you run (on the Hobbit server): bb 208.86.11.149 "pullclient"Absolutely nothing. Hrm. Checking the client's hobbitclient.log, I get lots of "Whoops ! bb failed to send message - timeout" The other logs have nothing interesting; successful startup, etc. Where do I go next to track down the timeout?
Check the IP that your client is configured to send reports to. When you are using the msgcache/hobbitfetch combo, then BBDISP on your clients should be 127.0.0.1, instead of the IP of your real Hobbit server. Henrik
list Gregor Mosheh
▸
No, "bbd" checks the Hobbit daemon's network interface. "hobbitd" just provides some statistics about all of Hobbit, and goes red/yellow if any problems are logged to the hobbitd logfiles.
Ah, gotcha.
▸
Check the IP that your client is configured to send reports to. When you are using the msgcache/hobbitfetch combo, then BBDISP on your clients should be 127.0.0.1, instead of the IP of your real Hobbit server.
It's set to 127.0.0.1 on all client machines. Still nothing coming in from
the bb pulldata command; therefore nothing showing up on the HTML page.
This did solve the timeouts in the hobbitclient.log
If I use --debug with bb, it shows a successful connection (status 0),
sending 8 bytes ("pulldata") and then disconnecting.