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%2BYnrJy%perryh@pluto.rain.com> In-Reply-To: <569F7C31.7010209@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Seaman <matthew@freebsd.org> wrote:
> On 01/20/16 11:07, Perry Hutchison wrote:
> > Matthew Seaman <matthew@freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56a0b441.FmUDB4FTgS%2BYnrJy%perryh>