DNSBL helper not answering

Vernon Schryver wrote:
> Those log lines do not show that dccifd should have started another helper
> process to wait for DNS answers.  They do show that after a helper dies
> of boredom, other helpers do a lot of failing.  I think all of lines are
> from helper processes complaining about DNS problems instead of the main
> dccifd process, because the PIDs vary.  The other possibility, that the
> main dccifd process is being very frequently restarted would imply
> a bigger problem than DNSBL helpers not being restarted.

You may be right... ps -eH yields:

  5321 ?        00:00:00   dccd
  5445 ?        00:00:00   dccifd
  5446 ?        00:00:01     dccifd
  5449 ?        00:00:01       dccifd
  5450 ?        00:00:00         dccifd
  5451 ?        00:00:00         dccifd
  2043 ?        00:00:00   dccifd

whereas the mail log file mentions completely different PIDs, except for 
2043, which is a DNSBL helper that has just been started.

> Does your resolver library not have _res.retry and _res.retrans like the
> BIND resolver library?
> Those log lines suggest a total DNS timeout of at least 1:23.  Unless the
> per-URL and per-message timeouts are at least as long, there will be problems.
> With ressolver timeouts of 83 seconds and shorter dccifd -B timeouts,
> the main dccifd process will frequently decide that the helpers are stuck
> and try to make new batches of helpers.


> 
> If your resolver library has _res.retry and _res.retrans,
> then perhaps it does not have resolv.h and arpa/nameser.h.
> What does include/dcc_config.h say about these?
>     HAVE_RESOLV_H 
>     HAVE_ARPA_NAMESER_H 
>     HAVE__RES 
>     HAVE_RES_INIT 
>     HAVE_RES_QUERY
>     HAVE_DN_EXPAND

/* BIND resolver library */
#define HAVE_RESOLV_H 1
#define HAVE_ARPA_NAMESER_H 1
#undef HAVE__RES
#undef HAVE_RES_INIT
#undef HAVE_RES_QUERY
#undef HAVE_DN_EXPAND

- Daniel