Hi, same problem here; it used to look like this:
Oct 31 02:35:21 localhost fetchmail[3881]: starting fetchmail 6.3.4 daemon
Oct 31 02:35:21 localhost fetchmail[3881]: couldn't find canonical DNS name of
pop.gmx.net (pop.gmx.net)
Oct 31 02:35:22 localhost fetchmail[3881]: Query status=11 (DNS)
Oct 31 02:35:22 localhost fetchmail[3881]: Query status=2 (SOCKET)
Oct 31 02:40:01 localhost fetchmail[3881]: couldn't find canonical DNS name of
pop.gmx.net (pop.gmx.net)
Oct 31 02:40:01 localhost fetchmail[3881]: Query status=11 (DNS)
more recently it looks like this:
Nov 1 01:29:03 localhost fetchmail[3881]: starting fetchmail 6.3.4 daemon
Nov 2 16:38:39 localhost fetchmail[3881]: getaddrinfo("pop.gmx.net","pop3s")
error: Temporary failure in name resolution
Nov 2 16:38:40 localhost fetchmail[3881]: POP3 connection to pop.gmx.net
failed: Connection refused
Nov 2 16:38:40 localhost fetchmail[3881]: Query status=2 (SOCKET)
Nov 2 16:38:40 localhost fetchmail[3881]: Query status=2 (SOCKET)
Nov 2 16:53:40 localhost fetchmail[3881]: getaddrinfo("pop.gmx.net","pop3s")
error: Temporary failure in name resolution
Nov 2 16:53:40 localhost fetchmail[3881]: POP3 connection to pop.gmx.net
failed: Connection refused
Nov 2 16:53:40 localhost fetchmail[3881]: Query status=2 (SOCKET)
Nov 2 16:53:40 localhost fetchmail[3881]: Query status=2 (SOCKET)
and when run in interactive mode, it all works fine.
I can't give you a '-v -v' output at the moment, because for me, the
problem occurs *only sometimes* and I think that is significant. Note
that for Eike, the problem is with the first entry in ~/.fetchmailrc -
same is true here, all other servers (I poll two) are queried just fine.
My system is not permanently connected to the internet (it's a laptop),
and the impression I have as to what happens is that when fetchmail
first starts up, name resolution doesn't work yet so the first server
gives an error, and this error is then stored permanently somewhere - a
bug in getaddrinfo()?
Florian
signature.asc
Description: Digital signature
