NSCA processes hanging around

[Gareth Watson]

Hello,

Over time I notice a number (a large number, ~500) of nsca processes
hanging around. I used netstat to see what they were up to and they
where all in the TIME_WAIT status.

Reading on the internet I think I understand what this means. Linux is
not closing the socket as it is waiting for any delayed traffic on the
network to appear. I have no problem with this as my first thought would
be that I will see a slow shift in the process numbers as sockets are
eventually closed and opened by new requests. This is not, however, the
behaviour I observed! The processes would wait indefinitely.

Now, clutching at straws I think I have managed to fix the problem. I
removed the REUSE flag from the nsca xinetd configuration:

# default: on
# description: NSCA
service nsca
{

#Commented out the line below in the vain hope it would fix nsca's wagon

#FLAGS = REUSE 
socket_type = stream 
wait = no 
user = nagios 
group = nagios 
server = /usr/local/nagios/bin/nsca 
server_args = -c /usr/local/nagios/etc/nsca.cfg --inetd log_on_failure
+= USERID 
disable = no 
}

Again some research on the net has told me a little bit about the REUSE
flag but I wanted to gather the opinions from those with much more
knowledge than I. Therefore, can anyone tell me if this is a reasonable
thing to do? Have I made a grievous error without even knowing? Has
anyone else experienced this behaviour?

I really appreciate anyone who has taken the time to read this and would
love some feedback if you get the chance.

Many thanks, 

Gareth Watson


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nagios-users mailing list
Nagios-users at 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