Francesco,

this is not at all useful without further logs and traces; reopening the
bugs you should have seen what information and research we've had to do
to find the bug and that it was considered fixed for half a decade.

It is very likely that relevant regressions, if any and not real
temporary issues, are caused by changes in the resolver rigging (name
server, lwresd, whatever, plus nscd and other daemons used by the libc);
and in that situation, I will need API documentation to the extent that
it allows me, from fetchmail code, to reinitialize the resolver library.


Nico,

what is the resolver configuration in the fetchmail build, what daemons
is libc supposed to use on the affected systems?  Is lwresd involved?


Francesco,

I will also need further logs to evidence:

- please show me the config.h and config.log (perhaps Nico can dig these
  out from buildd logs, too)

- that the bug persists in fetchmail 6.3.26 which is the current
  upstream version,

- the fetchmail configuration and logs per FAQ item #G3
  (URL earlier in the bug),

- a documentation of resolv.conf, host.conf, nsswitch.conf before/after
  changes, and how that relates to resolver trouble,

- a proof that nscd is not running and providing negative cache
  entries, or is otherwise having its cache flushed when nsswitch.conf
  changes,

- an ltrace excerpt showing how fetchmail is attempting to resolve the
  relevant names or reinitializing the resolver library (or not)

- proof that other software can resolve the names in the very same
  instant (a fake poll entry with ssh for its plugin might do that).

Best regards
Matthias Andree


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to