AW: kern.openfiles limit on FreeBSD

>> On Wed, 2005-02-02 at 16:41 +0100, Bolmerg-Berliner Ludger -
Munich-MR
>> wrote:
>
>> When I stop the sendmail process kern.openfiles does not decrease.  
>> But restarting dccifd will decrease the value from >4000 to something

>> like 300
>
> The command `fstat -p X` where X is the PID of the dccifd daemon might
be illuminating.
>

Strange enough fstat does not show a large amount of open files for
dccifd

Here is what I see from pstat and fstat 

#pstat -T
2197/15000 files
434M/2048M swap space

No of open files in the systems is 2197 out of a maximum allowed of
15000

#fstat -p `cat /var/run/dcc/dccifd.pid`
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W
root     dccifd     63742 root /             2 drwxr-xr-x     512  r
root     dccifd     63742   wd /var     10103808 drwxr-xr-x     512  r
root     dccifd     63742 text /var     10104050 -r-xr-xr-x  413429  r
root     dccifd     63742    0 /dev         16 crw-rw-rw-    null rw
root     dccifd     63742    1 /dev         16 crw-rw-rw-    null rw
root     dccifd     63742    2 /dev         16 crw-rw-rw-    null rw
root     dccifd     63742    3* pipe c23d2180 <-> c23d222c      0 rw
root     dccifd     63742    4* pipe c23d222c <-> c23d2180      0 rw
root     dccifd     63742    5* local stream c2d82ec4
root     dccifd     63742    6 /var     10103898 -rw-------    7532 rw
root     dccifd     63742    7 /var     10103862 -rw-r--r--   49108 rw
root     dccifd     63742    8* local dgram c27d4000 <-> c27d4118
root     dccifd     63742   17* internet dgram udp c2bd7ec4
root     dccifd     63742   19* internet dgram udp c2e100b4
root     dccifd     63742   21* internet dgram udp c2da3384
root     dccifd     63742   23* internet dgram udp c2d7d9d8
root     dccifd     63742   25* internet dgram udp c2d6cca8
root     dccifd     63742   26* internet dgram udp c2c189d8
root     dccifd     63742   27* internet dgram udp c27580b4
root     dccifd     63742 1697* local stream c27c1c08 -> c47e24ec
root     dccifd     63742 1698* local stream c2d82dac -> c2cbc1a4
root     dccifd     63742 1770 /var     10123663 -rw-------    2487 rw
root     dccifd     63742 1771 /var     10123664 -rw-------    1535 rw
root     dccifd     63742 1772 /var     10103822 -rw-r--r--    3569 rw
root     dccifd     63742 1773 /var     10103823 -rw-r--r--   12124  r

This looks prety reasonable to me.
After restarting dccifd with /var/dcc/libexec/dccifd I get

#pstat -T
386/15000 files
434M/2048M swap space

The number of open files went down to 386

Again, I am not blaming dccifd, I just do not understand what's
happening .  After a reboot the system is running ok for a while (30 min
to an hour) and than something happens that triggers this behaviour.
Besides DCC, SA and sendmail nothing else is running on that box except
the standard daemons and my telnet sessions.

The same set up was running on FreeBSD 5.2.1 without any issues.

Anyway, I will have to go back to the old system as I cannot afford this
on a production machine. 

> How is dccifd involved?  Via SpamAssassin?  Could the problem be that
SpamAssassin is not closing connections to > dccifd?  I use dccifd for a
little traffic and see no signs of a file descriptor leak.
>

dccifd is called by SA, it could also be SA related

> It is usually best to use dccm with sendmail and so reject spam during
the SMTP transaction than to use 
> SpamAssassin with dccifd to discard or categorize spam after having
received it.
>
> Judging from some exeriments, many spammers are aggressively pruning
their lists of (apparently) non-deliverable > addresses.  The more mail
your system rejects, they'll leave it alone.

You may be right, at least it is a point for discussion, but it won't
solve my problem here

Regards,
Ludger