Milter-greylist

On Thu, Sep 27, 2007 at 05:17:38AM +0200, manu@... wrote:
> Johann Klasek <johann@...> wrote:
> 
> >   - Up to Solaris 9 the default file descriptor limit is set to 256. As
> >       long this is not increased the basic libc stdio file handle
> >       problem does not come into play. Milter-greylist will just exit
> >       because the file *descriptor* limit hits. This rapidly happens
> >       on higher request rates (spam attack) when concurrent sessions
> >       are going to lift up.
> >       In low traffic environments this will not happen often.
> 
> Ok, so this problem is just popping up now because of traffic raise? If
> that's the case, then people using older releases of milter-greylist
> should have been burnt too, and if they have not yet, then it means they
> can safely upgrade, right?
> 
> Do I understand the problem correctly: when you hit this Solaris
> limitation, fopen/fdopen fails, returning NULL with errno == 0, right?

To be exactly, Solaris libc leaves errno untouched (the latest value is
preserved ...). Therefore it is necessary to explicit clear errno before
calling fdopen/fopen to distinguish file handle error from "normal"
errors ...

> 
> A simple way of fixing the issue would just be to issue a TEMPFAIL in
> this situation, which would reflect the real problem: your system cannot
> function proprely because of resource exhaustion, and the sender should
> retry later.
> 
> Of course, if there is a file descriptor leak in milter-greylist, we are
> screwed, because you won't ever be able to cope with the situation. But
> nobody reported that kind of problem so far.

I don't think there is no general file descriptor leak problem - this
had been revealed during the work on my Solaris work around.

The only leaking problem regarding file descriptor comes with configure
option --enable-dnsrbl which uses the resolver routines and the
threadsafe interface recognition in dnsbl.c (in plain 3.0 and at least
up to 4.0a6) module fails (at least for Solaris, but do work for Linux).
Multiple threads are then calling the not reentrant resolver routines
which leads to an overwritten static data condition and "lost"
descriptors which the resolver will never see again (staying around
unclosed ...).


Johann