On Thu, 2011-03-17 at 16:00 -0700, Mike Lindsey wrote:
I have a notification command that will typically take longer to run,
than my notification timeout. I don't particularly care, if Nagios gets
a valid return code back, so I set the main script to fork twice, with
the initial process printing 'OK' and exiting with a return code of 0.
The child process also exits immediately with a return code of 0, while
the grandchild hangs around to do some heavy lifting.
I was hoping that the double-fork would keep Nagios from blocking on the
process, but the debug logs are still showing:
[1300401208.452280] [032.1] [pid=55343] Adding normal contacts for
service to notification list.
[1300401239.455867] [032.0] [pid=55343] 1 contacts were notified. Next
possible notification time: Fri Mar 18 03:33:28 2011
When I'm expecting the '1 contacts were notified' to happen pretty much
immediately.
Any ideas to get around this, other than writing out a spool file and
having a secondary daemon handle the heavy lifting?
This sounds like the same issue I had my ocsp_command script. The main
nagios program was waiting on the grandchild even though the child had
returned already. In my case it was because the grandchild still had
filehandles back to to nagios open. When I closed filehandles 4 and 5
in the grandchild before it went off to do its real work I got the
desired behavior; nagios considered the script run once the child
returned, and grandchild was to free to take as long as it needed to
complete.
M.
--
... with eskimo chain i tattooed my brain all the way...
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
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
