[Mimedefang] Problem: Filter did not create RESULTS file

[Jeremy McCarty]

On Solaris under a larger load, there appears to be a problem with using
fopen and likely running out of streams (max 20 per process?).

We are seeing this error, "Filter did not create RESULTS file", by the
hundreds when the system gets a larger number of messages to process
concurrently.  Here is the difference between MD failing or succeeding with
this error.

truss of fails:

21978/1864:     open("/var/spool/MIMEDefang/mdefang-h6MFLYTE014872/RESULTS", O_RDONLY) = 271
21978/1816:     poll(0xF647F030, 1, 7210000)                    = 1
21978/1887:     write(54, "\n", 1)                              = 1
21978/1898:     write(63, 0x00065F49, 28)                       = 28
21978/1898:        x x x x x x x x x x x x x x x x x x x x x x x x x x x x
21978/1864:     close(271)

21978/1898:     open("/var/spool/MIMEDefang/mdefang-h6MFLUTE014782/RESULTS", O_RDONLY) = 295
21978/1738:     fstat64(117, 0xF617B750)                        = 0
21978/1865:     write(330, 0x000471B5, 32)                      = 32
21978/1865:        x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
21978/1891:     unlink("/var/spool/MIMEDefang/mdefang-h6MFLdTE014939/RESULTS") = 0
21978/1898:     close(295)


truss of succeeds:

21978/1829:     open("/var/spool/MIMEDefang/mdefang-h6MFLHTE014729/RESULTS", O_RDONLY) = 7
21978/1829:     fstat64(7, 0xFC2FD9C8)                          = 0
21978/1829:     ioctl(7, TCGETA, 0xFC2FD954)                    Err#25 ENOTTY
21978/1829:     read(7, 0x000578BC, 8192)                       = 141

21978/1738:     open("/var/spool/MIMEDefang/mdefang-h6MFLKTG014747/RESULTS", O_RDONLY) = 38
21978/1738:     fstat64(38, 0xFDF7D9C8)                         = 0
21978/1738:     ioctl(38, TCGETA, 0xFDF7D954)                   Err#25 ENOTTY
21978/1738:     read(38, 0x0005792C, 8192)                      = 120

21978/1857:     open("/var/spool/MIMEDefang/mdefang-h6MFLRTE014766/RESULTS", O_RDONLY) = 41
21978/1903:     lstat("/var/spool/MIMEDefang/mdefang-h6MFLRTF014777/Work/msg-22685-379.msg", 0xFBFFA75C) = 0
21978/1903:     unlink("/var/spool/MIMEDefang/mdefang-h6MFLRTF014777/Work/msg-22685-379.msg") = 0
21978/1857:     fstat64(41, 0xFC47D9C8)                         = 0
21978/1903:     lstat("/var/spool/MIMEDefang/mdefang-h6MFLRTF014777/Work/msg-22685-380.txt", 0xFBFFA75C) = 0
21978/1857:     ioctl(41, TCGETA, 0xFC47D954)                   Err#25 ENOTTY
21978/1903:     unlink("/var/spool/MIMEDefang/mdefang-h6MFLRTF014777/Work/msg-22685-380.txt") = 0
21978/1903:     lstat("/var/spool/MIMEDefang/mdefang-h6MFLRTF014777/Work/msg-22685-381.html", 0xFBFFA75C) = 0
21978/1857:     read(41, 0x00057A14, 8192)                      = 120

21978/1902:     open("/var/spool/MIMEDefang/mdefang-h6MFLXTE014855/RESULTS", O_RDONLY) = 99
21978/1:        lwp_cond_signal(0xFF0F5548)                     = 0
21978/1902:     fstat64(99, 0xFC5FD9C8)                         = 0
21978/1902:     ioctl(99, TCGETA, 0xFC5FD954)                   Err#25 ENOTTY
21978/1738:     lwp_cond_wait(0xFF0F5548, 0xFF0F5558, 0xFF0EEDB0) = 0
21978/1902:     read(99, 0x000578BC, 8192)


The problem does not happen with file descriptor use for COMMANDS, INPUTMSG,
HEADERS, etc.  Any chance the use of fopen can be removed from MD?

Other than this problem, MD 2.33/SA/uvscan has been working well for us in
currently handling around 120,000 incoming messages per day and spam tagging
30,000 of those.  An additional 60,000 messages a day are rejected upfront by
DNSBLs.  Thanks David!

We were having different load problems with 2.30 and unique file names
colliding.  The use of Sendmail's queue id and other load enhancing changes
has made it better.  Thanks for the updates!

Jeremy