dccm running out of file descriptors

> From: Gary Mills <mills@cc.UManitoba.CA>

> ...
> > > dccm    14294 daemon 3667u  IPv4 0x3002d0361f0      0t0     TCP electra.cc.umanitoba.ca:*->electra.cc.umanitoba.ca:* (IDLE)

> ...
> > 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.

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

I don't see how lsof and netstat can be agreein.  I should check
the BSD netstat source, but I'm fairly confident that when netstat
says *.*, it means INADDR_ANY or 0.  There is no sane way to convert
a zero IP address to a host name, unless your hostname database
(DNS, YP/NIS, /etc/hosts) has some rather odd and unusual entries.
Maybe Solaris differs.

This matters because it matters whether the bogus sockets are being
created but never bound with bind() or connect() or somehow made idle
after being used but never closed.  I've looked at the DCC source but
see no way a newly created socket can escape close() and bind()/connect().

It's harder to determine that there is no case where a previously
bound socket is forgotten without being closed with close().

I've glanced at the sendmail milter library source, and didn't see
anything of the sort.

Is there any chance there are 3000 complaints from sendmail on
the other machine about problems talking to dccm?


Vernon Schryver    vjs@rhyolite.com