dccm running out of file descriptors

Gary Mills mills@cc.UManitoba.CA
Tue Feb 3 00:23:36 UTC 2004


On Mon, Feb 02, 2004 at 09:32:49AM -0700, Vernon Schryver wrote:
> > From: Gary Mills <mills@cc.UManitoba.CA>
> 
> > ...
> > 2832 IDLE
> 
> >       *.*                  *.*                0      0 24576      0 IDLE
> 
> > COMMAND   PID   USER   FD   TYPE        DEVICE SIZE/OFF    NODE NAME
> > dccm    14294 daemon 3667u  IPv4 0x3002d0361f0      0t0     TCP electra.cc.umanitoba.ca:*->electra.cc.umanitoba.ca:* (IDLE)
> 
> That seems significantly different from the previous lsof lines:
> 
> dccm    9546 daemon 3910u  IPv4 0x30002868bd0      0t0     TCP electra.cc.umanitoba.ca:*->naos.cc.umanitoba.ca:* (IDLE)

No, those are just the two different sendmail hosts.  Both of them
appear in the lsof output.  80 or 90% of the IDLE connections have
electra as the remote host.

> The new lines that have electra.cc.umanitoba.ca as the remote host
> do look like idle sockets that have been created with socket() system
> calls but not used.  Perhaps the previous lsof lines were bogus
> due to a confusion in lsof about what it should say for INADDR_ANY or 0.

No, I'd say that lsof and netstat agree.  I don't know why lsof shows
hostnames, but netstat does not.

> > 2285 TIME_WAIT
> 
> That's odd.  Why would a socket that was in the TCP IDLE state
> need to go to the TIME_WAIT state when it is closed?   That casts
> doubt on the idea that the IDLE states are real, and bolsters the
> notion of a missing close() in some error path in either dccm or
> the milter library.  Since it is the milter library that closes
> the sockets, I've two reasons for suspecting the library.

Those are not necessarily the same sockets.  In normal operation,
there are a large number of TCP connections on the system that are
in the TIME_WAIT state.  In fact, I've had to reduce the timeout to
keep them down to a reasonable number.  Incoming SMTP connections
sometimes hit 40 per second, which can result in an enormous number
of closed connections in TIME_WAIT.

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.