From owner-freebsd-stable@FreeBSD.ORG Tue Sep 28 18:43:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C546110656A3 for ; Tue, 28 Sep 2010 18:43:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 733C88FC12 for ; Tue, 28 Sep 2010 18:43:45 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id CB5s1f00A1c6gX853Jjl8N; Tue, 28 Sep 2010 18:43:45 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta23.westchester.pa.mail.comcast.net with comcast id CJjk1f0063LrwQ23jJjk3B; Tue, 28 Sep 2010 18:43:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 21C7D9B418; Tue, 28 Sep 2010 11:43:43 -0700 (PDT) Date: Tue, 28 Sep 2010 11:43:43 -0700 From: Jeremy Chadwick To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20100928184343.GA70384@icarus.home.lan> References: <4CA22FF0.8060303@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA22FF0.8060303@quip.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: fetch: Non-recoverable resolver failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 18:43:45 -0000 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 |