I have seen rights modified on the opsview_slave.log (IIRC) back to root.root which caused the slave to remain "in trouble"
Recent happenings result in slave error from the master, where a restart of the tunnel (ps -ef | grep ssh, pick the right ip of the slave and kill -9) fixed the problem. I guess this is some kind of intermediate networking issues which causes each side to think the tunnel is still up. Any chance the slave hasn't checked the service? reschedule the next check of the stale service and see what happens? hth Paul -----Original message----- To:[email protected]; From:Simone Felici <[email protected]> Sent:Fri 24-06-2011 09:17 Subject:Re: [opsview-users] Slave service results stale Maybe you've still tested it, but in case, take a look on the wiki: http://docs.opsview.com/doku.php?id=opsview-community:staleresults There are some suggestion and points to check. In my case there was an issue on the slave, executing as nagios user: /usr/local/nagios/bin/retrieve_opsview_info NRD was in stale and no results sent to the master: high backlog values. There are steps to test the ssh tunnel too which is important 'cause the informations are travelled into it :) You'll be able to simulate all steps OPSview should follow in case of a working scenario. Cheers, Simon Il 23/06/2011 18:16, Craig Pendleton ha scritto: > Thanks for the suggestion Simon, but that hasn't worked for me. A reboot of > both master and slave haven't cleared it up either. There must be a way to > get these checks working correctly again. Any other suggestions out there? > > _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/lists/listinfo/opsview-users
_______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/lists/listinfo/opsview-users
