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