Date: Tue, 28 Sep 2010 11:43:43 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-stable@freebsd.org Subject: Re: fetch: Non-recoverable resolver failure Message-ID: <20100928184343.GA70384@icarus.home.lan> In-Reply-To: <4CA22FF0.8060303@quip.cz> References: <4CA22FF0.8060303@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100928184343.GA70384>