All, It turned out to be memory... I found this out yesterday. I have an ESX VM running SLES9 and the default VM config is 256MB barely enough to run SLES. Amazingly it ran SLES, Smokeping, Cacti with no problem on 256MB of RAM! The problem cam when I installed Opennms, I think it pushed it over the edge when I added postgres on top of mysql, Tomcat on top on apache and finally the opennms application itself. I am not sure what other OS could have done all that only on 256MB of ram. Thanks for the response Niko. Robert
-----Original Message----- From: Niko Tyni [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 18, 2005 6:51 AM To: Robert Reilly Cc: [EMAIL PROTECTED] Subject: Re: [smokeping-users] unresponsive system On Sat, Oct 15, 2005 at 05:17:31PM -0400, Robert Reilly wrote: > I have smokeping logging that there are unresponsive systems in the > configuration, I see spots on all graphs for all clients at the same > time that there is no data, but I have checked each system and none have > any packet loss according to smoke ping. Yet during these times of no > data smoke ping is logging that a polling cycle took more the x seconds. > Is there a way to dump out which hosts are failing ? again the nodata > shows up for all hosts and no hosts show packet loss. Hi, you could try the '--debug-daemon' option, it produces lots of debug information in the log. Generally it would be best to tune the polling parameters so that unresponsive devices don't cause any problems. Which probe(s) are you using? If it's the FPing probe, you have to either increase the 'step' variable or decrease 'timeout' or 'pings'. If it's one of the others, you can also increase the 'forks' variable, which controls how many targets are probed concurrently. HTH, -- Niko -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://lists.ee.ethz.ch/smokeping-users WebAdmin http://lists.ee.ethz.ch/lsg2.cgi
