From owner-freebsd-questions@freebsd.org Thu Jan 21 10:41:00 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0799BA8A355 for ; Thu, 21 Jan 2016 10:41:00 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7A601221 for ; Thu, 21 Jan 2016 10:40:59 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id u0LAa4Wf029421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 21 Jan 2016 02:36:07 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id u0LAa4qg029419 for freebsd-questions@freebsd.org; Thu, 21 Jan 2016 02:36:04 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA13923; Thu, 21 Jan 16 02:34:54 PST Date: Thu, 21 Jan 2016 02:34:41 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd-questions@freebsd.org Subject: Re: resolver not working in a chroot Message-Id: <56a0b441.FmUDB4FTgS+YnrJy%perryh@pluto.rain.com> References: <569e05b6.2RStkLc7SZIg/dVM%perryh@pluto.rain.com> <569E12B2.5090302@freebsd.org> <569eeb77.GFz8dwXgj3CL44SN%perryh@pluto.rain.com> <569F44DB.4080406@FreeBSD.org> <569f6a72.IDjZt6e6TrIMfmrk%perryh@pluto.rain.com> <569F7C31.7010209@freebsd.org> In-Reply-To: <569F7C31.7010209@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 10:41:00 -0000 Matthew Seaman wrote: > On 01/20/16 11:07, Perry Hutchison wrote: > > Matthew Seaman wrote: > >> In order to track down exactly what the problem is I'd be running > >> that ping command under truss(1) ... > > > > Having truss run the chroot showed that the resolver is correctly > > deciding to consult the DNS after failing to find the hostname in > > /etc/hosts -- /etc/nsswitch.conf specified "hosts: files dns" -- > > then falling over when it tries to open a socket for the purpose: > > > > open("/etc/hosts",0x100000,0666) = 4 (0x4) > > fstat(4,{ mode=-rw-r--r-- ,inode=12102,size=1090,blksize=8192 }) = 0 (0x0) > > read(4,"# $FreeBSD: releng/10.2/etc/host"...,8192) = 1090 (0x442) > > read(4,0x28820000,8192) = 0 (0x0) > > close(4) = 0 (0x0) > > gettimeofday({1453281421.449818 },0x0) = 0 (0x0) > > kqueue(0x0,0xbfbecccc,0x8,0x7273752f,0x62696c2f,0x28060aae) = 4 (0x4) > > socket(PF_INET,0x10000002,0) ERR#43 'Protocol not supported' > > ... > > write(2,"ping: ",6) = 6 (0x6) > > write(2,"cannot resolve pkg.FreeBSD.org: "...,56) = 56 (0x38) > > ... > > The most glaring difference is that 0x10000002 second parameter > > that the resolver passes to socket(2): it should be SOCK_DGRAM > > ... > > Looks like ping(8) is OR-ing SOCK_CLOEXEC into the 2nd argument to > socket(2). That's perfectly fine according to the manual. The > 'Protocol not supported' error you're seeing is not because of that. > > Hmmm.... > > You've mounted a 10.2-RELEASE memstick image onto /mnt, but what OS > version is the parent host running? 8.something, and I think that's the cause of the resolver problem. There is no definition of SOCK_CLOEXEC in /usr/include/*.h or /usr/include/sys/*.h (although there is a definition of FD_CLOEXEC in fcntl.h). I gather that the ability to OR such things into the type parameter of socket(2), rather than having to make a separate fcntl(2) call, was added subsequently. > If you're trying to run a more recent version of the OS in the > chroot than in the host system, that could well explain your > experiences. The FreeBSD kernel is not guaranteed to be forward > compatible to software compiled on a more recent version of the > OS, although the reverse -- newer kernel and older software -- > will work. Certainly a newer userland program may require kernel facilities not provided by an older kernel, and fail if they are missing. However I don't expect the kernel ABI to change gratuitously, because that would impair the ability of older userland programs to run on newer kernels. In this case, it looks as if the 10.2 resolver requires an enhancement to the socket(2) ABI that was not in the host kernel. I suppose I could import the 10.2 kernel into the 8.x /boot and try running the existing 8.x userland with the newer kernel long enough to get this particular investigation (which involves considerably more than ping(8)) done.