Fw: fork() problem?

[Mike Culbertson]

That was my assumption to begin with.  At the time when I left nagios
unattended and returned to find 1900+ nagios processes,
max_concurrent_checks was and had been set to 0.  The other box I run
exhibits none of this behavior though it is configured differently.  I
have a hunch that this may have something to do with my passive service
checks (performed using NSCA), as nscd forks somewhat congruently
(although in far smaller quantity) with nagios.  I'm thinking maybe
something is wrong with the build running on linux.or maybe this is
something specific to 1.0b6?  I haven't been able to roll back to 1.0b5
yet to see if it acts differently (nor do I really want to).  I suppose
the question is what would cause a child process to not complete its
task and just sit there?  I should also point out that despite the huge
number of forked procs, nagios did not cease to function, and there were
no zombie procs.  Thanks for the input.
 
Mike C
 
-----Original Message-----
From: Richard Wu [mailto:Richard.Wu at fusepoint.com] 
Sent: Monday, October 21, 2002 6:17 PM
To: Mike Culbertson
Cc: nagios-users at lists.sourceforge.net
Subject: RE: [Nagios-users] Fw: fork() problem?
 
Hi, mike:
 
If you want the nagios to be run in parallel, set the value to 0, look
at the nagios.cfg comments on the max_concurrent_checks. Here is the
contnet:
# MAXIMUM CONCURRENT SERVICE CHECKS
# This option allows you to specify the maximum number of
# service checks that can be run in parallel at any given time.
# Specifying a value of 1 for this variable essentially prevents
# any service checks from being parallelized.  A value of 0
# will not restrict the number of concurrent checks that are
# being executed.
 
max_concurrent_checks=0
Richard Wu 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20021021/6b1b7f67/attachment.html>