Re: Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
On Fri, Jun 29, 2012 at 1:41 PM, Steven Chamberlain <steven@pyro.eu.org> wrote:
> reassign 679198 src:kfreebsd-9
> affects 679198 src:bash
> retitle 679198 bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
> thanks
>
> On 29/06/12 03:19, Stefan Ott wrote:
>> I suppose that narrows it down a little. I'm more and more inclined to
>> blame ZFS.
>
> But /dev/null itself is on a devfs so I doubt it could have any effect.
Ha, good point, I guess it's too hot for me to think properly atm.
>> 74149 preinst CALL open(0x401ae4,0x1<><invalid>1,<unused>0)
>> 74149 preinst NAMI "/dev/null"
>> 74149 preinst RET open 3
>> 74149 preinst CALL fcntl(0x3,<invalid=3>,0)
>> 74149 preinst RET fcntl 1
>> 74149 preinst CALL fcntl(0x3,<invalid=4>,0x1<><invalid>1)
>> 74149 preinst RET fcntl -1 errno 25 Inappropriate ioctl for device
>
> There is a crucial difference; in my ktrace (with GNU/kFreeBSD host)
> the file was opened with the FD_CLOEXEC flag set already. Not sure how
> that happens, but I guess something different in how our kernel is built.
Interesting. If you have a ideas / patches that I could try out I
would be happy to.
> In the above (with upstream FreeBSD as host) it was not, and trying to
> enable it failed. From reading http://bugs.debian.org/635192 it sounds
> like that might be a limitation of our glibc.
Ah indeed, that does look related.
> Implementing it could be a problem for the 8.1 kernel of squeeze and as
> used on our buildds, and so I don't think it could be properly fixed
> until wheezy+1, at least.
>
> A workaround in bash might have been justified, but AFAIK this problem
> is specific to GNU/kFreeBSD chroot/jails on native FreeBSD hosts.
True, it's probably a rare combination. I suppose if it affects just
me you can leave it for now, the next couple of months will tell us
whether anyone else is running this combination.
cheers & thanks for looking into it
--
Stefan Ott
http://www.ott.net/
"You are not Grey Squirrel?"
Reply to: