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
