Marc Powell wrote: > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:nagios-users- >> [EMAIL PROTECTED] On Behalf Of Lars Stavholm >> Sent: Tuesday, March 27, 2007 4:44 PM >> To: nagios-users@lists.sourceforge.net >> Subject: [Nagios-users] service timeout >> > > >> Q: Is there any way one could define time out on one service >> rather than all services? > > Standard plugins mostly support a -t switch to specify the timeout for > the plugin. The nagios.cfg service check timeout is a catch-all for > those that don't terminate themselves when they should. Ideally, each > command definition would have a specific timeout for each plugin defined > with -t and the nagios.cfg timeout would be the max possible value of > your timeouts. In that scenario individual plugins would have unique > timeout values and your max would catch any runaways. You could go > further with that and actually pass the timeout value as a $ARGx$ macro > to the command from your service definition allowing you very specific > granularity in your timeout control. > > Since the duration of the run-time for your check is so long, I agree > that it probably makes more sense to either run it out of cron and have > it submit a passive check result or have it update a file that you then > parse as an active check in nagios.
Thanks for that. The plugin in question (check_rootkit) is a simple shell without any timeout option. I'm going for the passive check solution. Thank you /Lars ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
