Re: [fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

[Matthias A. <mat...@gm...>]

On Wed, 28 Jun 2006, Uli Zappe wrote:

> Well, you *can* call getaddrinfo() a second time before calling  
> freeaddrinfo() first in Mac OS X without a crash or anything, and  
> it's thread-safe since Mac OS X 10.2 (though not before). The only  
> thing is that if you call it again with exactly the same query data  
> and without calling freeaddrinfo() in between, it will report the  
> data it cached from the last call. You might call this a bug, but  
> Apple most probably will call it a feature ... Note that on Mac OS X,  
> getaddrinfo() is nothing more than a wrapper around the system's so- 
> called "lookupd" daemon, which handles all network addressing issues  
> with code that's completely different from all other Unix  
> implementations.

Nothing wrong here.

> If with "amount of time" you refer to the fact that the Internet must  
> be down a certain amount of time for the issue to occur, this seems  
> to be because the DNS data is cached for a certain amount of time,  
> either by getaddrinfo() itself, or by Mac OS X's local caching BIND,  
> or possibly by the caching name server of my router. Only when  
> there's no cache anymore and getaddrinfo() (unsuccessfully) tries to  
> retrieve that query data anew from the Internet, the timeout  
> interruption will occur and prevent freeaddrinfo() from being called.
> 
> At least that's how I interpret all these error lines in my  
> logfiles. ;-)

Well, that's plausible, but I wonder if the resolver would finally
recover a long time after the network connection has been restored - and
perhaps if the negative TTL of cache entries can be configured.

But OTOH, if you say that proper freeaddrinfo() use avoids the problem,
then we don't need to think about this part, because I will add the
missed freeaddrinfo() calls.

> Maybe it's a good idea to check for all occurrences of freeaddrinfo()  
> whether they are certain to be performed whenever they should.  
> Glimpsing at the code, e.g. in servport.c, line 65, the default  
> switch condition is a goto jump that prevents freeaddrinfo() from  
> being called, although it should be called (getaddrinfo() had  
> returned 0/success before, so "res" had been allocated). It seems  
> that calling freeaddrinfo() was not taken all too seriously  
> throughout fetchmail.

I'll defend myself by calling these plain bugs, rather than not taking
these calls "not ... too seriously".

> Well, the force of the laws of logic isn't polite ... ;-)  (This was  
> not meant to be a social "must" but rather a logical one, as I indeed  
> see no other programming techniques to deal with that issue.)

Perhaps not in C. In the long run (fetchmail 7 or thereabouts), I might
switch to something more OOP-like so I can use objects that know how to
destruct themselves. (C++ is most likely from today's point of view.)

> Well, that's more than OK with me! If you deal with bugs in  
> connection with Mac OS X, what you are afraid of are months or years  
> until a fix is applied - days are no problem at all.  :-)

Alright. Below is a fix to the problem you reported for servport.c (it
was easy to fix), please try and let me know if MacOS X works with the
IPPROTO_TCP stuff.  The other getaddrinfo() calls require more attention
and I'll see to them later.
The "NEWS" hunk below will probably fail to apply, this is harmless.

-- 
Matthias Andree