freebsd stable - Sep 2010 - fetch: Non-recoverable resolver failure

Hi,

we are using fetch command from cron to run PHP scripts periodically and 
sometimes cron sends error e-mails like this:

fetch: https://hiden.example.com/cron/fiveminutes: Non-recoverable 
resolver failure

The exact lines from crontab are:

*/5  * * * * fetch -qo /dev/null 
"https://hiden.example.com/cron/fiveminutes"

*/5  * * * * fetch -qo /dev/null 
"http://another.example.com/wd.php?hash=cslhakjs87LJ3rysalj79"

Network is working without problems, resolvers are working fine too. I 
also tried to use local instance of named at 127.0.0.1 but it did not 
fix the issue so it seems there is some problem with fetch in phase of 
resolving address.

Note: target domains are hosted on the server it-self and named too.

The system is FreeBSD 7.3-RELEASE-p2 i386 GENERIC

Can somebody help me to diagnose this random fetch+resolver issue?

Miroslav Lachman

On Tue, Sep 28, 2010 at 08:12:00PM +0200, Miroslav Lachman
wrote:
> Hi,
> 
> we are using fetch command from cron to run PHP scripts periodically
> and sometimes cron sends error e-mails like this:
> 
> fetch: https://hiden.example.com/cron/fiveminutes: Non-recoverable
> resolver failure
> 
> The exact lines from crontab are:
> 
> */5  * * * * fetch -qo /dev/null
> "https://hiden.example.com/cron/fiveminutes"
> 
> */5  * * * * fetch -qo /dev/null
> "http://another.example.com/wd.php?hash=cslhakjs87LJ3rysalj79"
> 
> Network is working without problems, resolvers are working fine too.
> I also tried to use local instance of named at 127.0.0.1 but it did
> not fix the issue so it seems there is some problem with fetch in
> phase of resolving address.
> 
> Note: target domains are hosted on the server it-self and named too.
> 
> The system is FreeBSD 7.3-RELEASE-p2 i386 GENERIC
> 
> Can somebody help me to diagnose this random fetch+resolver issue?
The error in question comes from the resolver library returning
EAI_FAIL.  This return code can be returned to all sorts of applications
(not just fetch), although how each app handles it may differ.  So,
chances are you really do have something going on upstream from you (one
of the nameservers you use might not be available at all times), and it
probably clears very quickly (before you have a chance to
manually/interactively investigate it).

You're probably going to have to set up a combination of scripts that do
tcpdump logging, and ktrace -t+ -i (and probably -a) logging (ex. ktrace
-t+ -i -a -f /var/log/ktrace.fetch.out fetch -qo ...) to find out what's
going on behind the scenes.  The irregularity of the problem (re:
"sometimes") warrants such.  I'd recommend using something other
than
127.0.0.1 as your resolver if you need to do tcpdump.

Providing contents of your /etc/resolv.conf, as well as details about
your network configuration on the machine (specifically if any
firewall stacks (pf or ipfw) are in place) would help too.  Some folks
might want netstat -m output as well.

-- 
| Jeremy Chadwick                                   jdc@parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

On Tue, Sep 28, 2010 at 08:12:00PM +0200, Miroslav Lachman
wrote:
> The exact lines from crontab are:
> 
> */5  * * * * fetch -qo /dev/null 
> "https://hiden.example.com/cron/fiveminutes"
> 
> */5  * * * * fetch -qo /dev/null 
> "http://another.example.com/wd.php?hash=cslhakjs87LJ3rysalj79"
In addition to anything else, I suspect the question mark in
double-quotes might cause some shell-related interpretation;
perhaps single quotes will be safer...

-- 
Brian Reichert				<reichert@numachi.com>
55 Crystal Ave. #286			
Derry NH 03038-1725 USA			BSD admin/developer at large