Fri Oct 24 23:04:34 UTC 2003
> Whether you want F=T or nothing probably depend on how bad it is to > leak spam. The low FDSET limit and so low limit on concurrent dccm > jobs in BSD/OS might cause a lot of leaking spam with no F=T. I don't want leak more, but currently if dccm goes South but doesn't exit sendmail is shutdown until there is some outside intervention. > What about this script run from cron: I worked the Perl equivalent of that in to my dccm monitor and it seems to be doing the trick. > Not convinced of what, the theory that the problem is in the BSD/OS > resolver or that the problem can't be fixed except by figuring it out? That it's the resolver code. No question that BSD/OS DNS has problems with threads, but the library that ships with Bind 9.x is suppose to be thread safe. However linking against that library doesn't seem to change anything. I'm wondering if it's a deeper problem with threads in general. How much does dccm depend on DNS? One sure test would be to remove any DNS calls and see what happens...
More information about the DCC