Fw: fork() problem?

Richard Wu Richard.Wu at fusepoint.com
Tue Oct 22 20:12:36 CEST 2002


I  believe most of them are plugin checks, not the main daemon. Have you got a lot of plugin time out , how many service check you are having on that box and what's the frequency?
Richard Wu 
-----Original Message-----
From: Mike Culbertson [mailto:mike at omnipod.com]
Sent: Monday, October 21, 2002 8:20 PM
To: Richard Wu
Cc: nagios-users at lists.sourceforge.net
Subject: RE: [Nagios-users] Fw: fork() problem?


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/20021022/91d0ce0a/attachment.html>


More information about the Users mailing list