Bug#679198: bash: Fails to upgrade in kFreeBSD jails

Stefan Ott · External Since: Apr 04, 2009 Posts: 18

Package: bash
Version: 4.2-2
Severity: important

Hello,

I am running Debian GNU/kFreeBSD inside FreeBSD 9 jails. When I tried to
upgrade from squeeze to wheezy I got the following error:

Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 11090 files and directories currently installed.)
Preparing to replace bash 4.1-3 (using .../bash_4.2-2_kfreebsd-amd64.deb) ...
bash.preinst: cannot set close-on-exec flag: Inappropriate ioctl for device
dpkg: error processing /var/cache/apt/archives/bash_4.2-2_kfreebsd-amd64.deb (--unpack):
subprocess new pre-installation script returned error exit status 1
configured to not write apport reports
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode.
Errors were encountered while processing:
/var/cache/apt/archives/bash_4.2-2_kfreebsd-amd64.deb

I think this might be related to my root file system for the jail being ZFS
but I have to admit that I'm no expert on that. At any rate, is does make it
rather difficult for me to upgrade the package (as in, from what I know I
will have to manually edit the .deb and remove the preinst file) and it would
be nice if this could be fixed.

Let me know if you need access to such a jail in order to reproduce this,
I am sure that can be arranged.

-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 9.0-RELEASE-p3
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages bash depends on:
ii base-files 6.9
ii dash 0.5.7-3
ii debianutils 4.3.1
ii libc0.1 2.13-33
ii libncurses5 5.7+20100313-5

Versions of packages bash recommends:
ii bash-completion 1:1.99-3

Versions of packages bash suggests:
pn bash-doc <none>

-- Configuration Files:
/etc/bash.bashrc changed [not included]

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Jonathan Nieder · External Since: Feb 26, 2009 Posts: 684

Hi debian-bsd@,

Stefan Ott wrote:

> Package: bash
> Version: 4.2-2
[...]
> I am running Debian GNU/kFreeBSD inside FreeBSD 9 jails. When I tried to
> upgrade from squeeze to wheezy I got the following error:
>
> Extracting templates from packages: 100%
> Preconfiguring packages ...
> (Reading database ... 11090 files and directories currently installed.)
> Preparing to replace bash 4.1-3 (using .../bash_4.2-2_kfreebsd-amd64.deb) ...
> bash.preinst: cannot set close-on-exec flag: Inappropriate ioctl for device
[...]
> I think this might be related to my root file system for the jail being ZFS
> but I have to admit that I'm no expert on that. At any rate, is does make it
> rather difficult for me to upgrade the package (as in, from what I know I
> will have to manually edit the .deb and remove the preinst file) and it would
> be nice if this could be fixed.
>
> Let me know if you need access to such a jail in order to reproduce this,
> I am sure that can be arranged.

Thought you might be interested in this report, since it feels like a
libc or kernel bug. Hints?

Thanks,
Jonathan

> -- System Information:
> Debian Release: wheezy/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: kfreebsd-amd64 (x86_64)
>
> Kernel: kFreeBSD 9.0-RELEASE-p3
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages bash depends on:
> ii base-files 6.9
> ii dash 0.5.7-3
> ii debianutils 4.3.1
> ii libc0.1 2.13-33
> ii libncurses5 5.7+20100313-5
>
> Versions of packages bash recommends:
> ii bash-completion 1:1.99-3
>
> Versions of packages bash suggests:
> pn bash-doc <none>
>
> -- Configuration Files:
> /etc/bash.bashrc changed [not included]

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Jonathan Nieder · External Since: Feb 26, 2009 Posts: 684

Jonathan Nieder wrote:
> Stefan Ott wrote:

>> bash.preinst: cannot set close-on-exec flag: Inappropriate ioctl for device
[...]
> Thought you might be interested in this report, since it feels like a
> libc or kernel bug. Hints?

Of course I should give more context than that. Smile

That message comes from set_cloexec(), which is defined as follows:

void set_cloexec(int fd)
{
int flags = fcntl(fd, F_GETFL);
if (flags < 0 || fcntl(fd, F_SETFL, flags | FD_CLOEXEC))
die_errno("cannot set close-on-exec flag");
}

It is called on /dev/null and the two file descriptors returned from
pipe() to avoid leaking file descriptors.

Presumably this should be a warning instead of a fatal error or the
set_cloexec() calls could be dropped altogether. But why is fcntl()
failing?

Thanks,
Jonathan

diff --git i/debian/bash.preinst-lib.c w/debian/bash.preinst-lib.c
index bb13a166..701a5874 100644
--- i/debian/bash.preinst-lib.c
+++ w/debian/bash.preinst-lib.c
@@ -58,19 +58,10 @@ int exists(const char *file)
die_errno("cannot get status of %s", file);
}

-void set_cloexec(int fd)
-{
- int flags = fcntl(fd, F_GETFL);
- if (flags < 0 || fcntl(fd, F_SETFL, flags | FD_CLOEXEC))
- die_errno("cannot set close-on-exec flag");
-}
-
void xpipe(int pipefd[2])
{
if (pipe(pipefd))
die_errno("cannot create pipe");
- set_cloexec(pipefd[0]);
- set_cloexec(pipefd[1]);
}

void wait_or_die(pid_t child, const char *name, int flags)
diff --git i/debian/bash.preinst.c w/debian/bash.preinst.c
index 14baeab0..2badd2ae 100644
--- i/debian/bash.preinst.c
+++ w/debian/bash.preinst.c
@@ -85,8 +85,6 @@ static int binsh_in_filelist(const char *package)
* fails, no problem; leave stderr alone in that case.
*/
sink = open("/dev/null", O_WRONLY);
- if (sink >= 0)
- set_cloexec(sink);
in = spawn_pipe(&child, cmd, sink);

/* ... | grep "^/bin/sh\$" */
diff --git i/debian/bash.preinst.h w/debian/bash.preinst.h
index 82faf497..4d4a5abb 100644
--- i/debian/bash.preinst.h
+++ w/debian/bash.preinst.h
@@ -26,7 +26,6 @@ extern NORETURN PRINTFLIKE void die_errno(const char *fmt, ...);
extern NORETURN PRINTFLIKE void die(const char *fmt, ...);

extern int exists(const char *path);
-extern void set_cloexec(int fd);
extern void xpipe(int pipefd[2]);

extern void wait_or_die(pid_t child, const char *desc, int flags);
diff --git i/debian/changelog w/debian/changelog
index 310ec061..40dcb4c5 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,11 @@
+bash (4.2-2.1) local; urgency=low
+
+ * bash.preinst: Let a few file descriptors leak instead of setting
+ the close-on-exec flag. This avoids some portability gotchas.
+ Closes: #679198.
+
+ -- Jonathan Nieder Tue, 26 Jun 2012 20:55:36 -0500
+
bash (4.2-2) unstable; urgency=low

* Fix command-not-found location. Closes: #529313.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Steven Chamberlain · External Since: Jan 19, 2006 Posts: 67

Hi,

Hmmm, I can't seem to reproduce the problem here, in a kfreebsd-i386
jail environment on a GNU/kFreeBSD (9.0) host. I had bash 4.2-2 already
installed though.

I'm trying "apt-get --reinstall install bash" or directly running
/var/lib/dpkg/info/bash.preinst

Here's a system call trace:

72202 bash.preinst CALL open(0x8049678,0x1<><invalid>1,<unused>0)
72202 bash.preinst NAMI "/dev/null"
72202 bash.preinst RET open 3
72202 bash.preinst CALL fcntl(0x3,<invalid=3>,0x8149)
72202 bash.preinst RET fcntl 1
72202 bash.preinst CALL fcntl(0x3,<invalid=4>,0x1<><invalid>1)
72202 bash.preinst RET fcntl 0

Successfully opened /dev/null as fd 0x3. I assume that is fcntl()
F_GETFL returning flags = 0x1 (which actually means FD_CLOEXEC was
already set), then F_SETFL returning 0 = success.

72202 bash.preinst CALL pipe
72202 bash.preinst RET pipe 4
72202 bash.preinst CALL fcntl(0x4,<invalid=3>,0x1)
72202 bash.preinst RET fcntl 2
72202 bash.preinst CALL fcntl(0x4,<invalid=4>,0x3<><invalid>3)
72202 bash.preinst RET fcntl 0
72202 bash.preinst CALL fcntl(0x5,<invalid=3>,0x28066d20)
72202 bash.preinst RET fcntl 2
72202 bash.preinst CALL fcntl(0x5,<invalid=4>,0x3<><invalid>3)
72202 bash.preinst RET fcntl 0

And successful in setting FD_CLOEXEC there on the pipe descriptors 0x4
and 0x5.

If this problem can still be reproduced, a ktrace[1] may be helpful, and
maybe the output from /proc/mounts and of course "ls -al /dev/null"

I don't have my jail in ZFS, but I guess devfs should be mounted at
/path/to/jail/dev anyway, or else /dev/null could be missing, and get
created as a regular file (which I also tried, and still couldn't
reproduce this failure).

[1]
http://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q._How_do_I_trace_system_calls.3F

Regards,
--
Steven Chamberlain
steven.RemoveThis@pyro.eu.org

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Stefan Ott · External Since: Apr 04, 2009 Posts: 18

Hey

On Fri, Jun 29, 2012 at 3:37 AM, Steven Chamberlain wrote:
> Hi,
>
> Hmmm, I can't seem to reproduce the problem here, in a kfreebsd-i386
> jail environment on a GNU/kFreeBSD (9.0) host. I had bash 4.2-2 already
> installed though.

I suppose that narrows it down a little. I'm more and more inclined to
blame ZFS.

> If this problem can still be reproduced, a ktrace[1] may be helpful

Here we go:

74149 ktrace RET ktrace 0
74149 ktrace CALL execve(0x7fffffffdd57,0x7fffffffdaf0,0x7fffffffdb00)
74149 ktrace NAMI "./preinst"
74149 ktrace NAMI "/lib/ld-kfreebsd-x86-64.so.1"
74149 preinst RET execve 0
74149 preinst CALL getuid
74149 preinst RET getuid 0
74149 preinst CALL geteuid
74149 preinst RET geteuid 0
74149 preinst CALL getgid
74149 preinst RET getgid 0
74149 preinst CALL getegid
74149 preinst RET getegid 0
74149 preinst CALL break(0x800823000)
74149 preinst RET break -1 errno 12 Cannot allocate memory
74149 preinst CALL
__sysctl(0x7fffffffd8a0,0x2,0x7fffffffd8ac,0x7fffffffd898,0,0)
74149 preinst SCTL "kern.osreldate"
74149 preinst RET __sysctl 0
74149 preinst CALL getuid
74149 preinst RET getuid 0
74149 preinst CALL access(0x80061b58b,0<F_OK>)
74149 preinst NAMI "/etc/ld.so.nohwcap"
74149 preinst RET access -1 errno 2 No such file or directory
74149 preinst CALL
mmap(0,0x2000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_ANON|MAP_TYPE|MAP_PRIVATE>,0xffffffff,0)
74149 preinst RET mmap 34366164992/0x800621000
74149 preinst CALL getuid
74149 preinst RET getuid 0
74149 preinst CALL access(0x80061dd00,0x4<R_OK>)
74149 preinst NAMI "/etc/ld.so.preload"
74149 preinst RET access -1 errno 2 No such file or directory
74149 preinst CALL open(0x80061b527,0<><invalid>0,<unused>0)
74149 preinst NAMI "/etc/ld.so.cache"
74149 preinst RET open 3
74149 preinst CALL fstat(0x3,0x7fffffffd0b0)
74149 preinst STRU invalid record
74149 preinst RET fstat 0
74149 preinst CALL mmap(0,0x212b,0x1<PROT_READ>,0x2<MAP_PRIVATE>,0x3,0)
74149 preinst RET mmap 34366173184/0x800623000
74149 preinst CALL close(0x3)
74149 preinst RET close 0
74149 preinst CALL getuid
74149 preinst RET getuid 0
74149 preinst CALL access(0x80061b58b,0<F_OK>)
74149 preinst NAMI "/etc/ld.so.nohwcap"
74149 preinst RET access -1 errno 2 No such file or directory
74149 preinst CALL open(0x7fffffffd0d0,0<><invalid>0,<unused>0)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/tls/x86_64/libc.so.0.1"
74149 preinst RET open -1 errno 2 No such file or directory
74149 preinst CALL stat(0x7fffffffd0d0,0x7fffffffd040)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/tls/x86_64"
74149 preinst RET stat -1 errno 2 No such file or directory
74149 preinst CALL open(0x7fffffffd0d0,0<><invalid>0,<unused>0)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/tls/libc.so.0.1"
74149 preinst RET open -1 errno 2 No such file or directory
74149 preinst CALL stat(0x7fffffffd0d0,0x7fffffffd040)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/tls"
74149 preinst RET stat -1 errno 2 No such file or directory
74149 preinst CALL open(0x7fffffffd0d0,0<><invalid>0,<unused>0)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/x86_64/libc.so.0.1"
74149 preinst RET open -1 errno 2 No such file or directory
74149 preinst CALL stat(0x7fffffffd0d0,0x7fffffffd040)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/x86_64"
74149 preinst RET stat -1 errno 2 No such file or directory
74149 preinst CALL open(0x7fffffffd0d0,0<><invalid>0,<unused>0)
74149 preinst NAMI "/lib/x86_64-kfreebsd-gnu/libc.so.0.1"
74149 preinst RET open 3
74149 preinst CALL read(0x3,0x7fffffffd2f8,0x340)
74149 preinst GIO fd 3 read 832 bytes
0x0000 7f45 4c46 0201 0109 0000 0000 0000 0000 |.ELF............|
0x0010 0300 3e00 0100 0000 40f4 0100 0000 0000 |..>.....@.......|
0x0020 4000 0000 0000 0000 2043 1400 0000 0000 |@....... C......|
0x0030 0000 0000 4000 3800 0a00 4000 2400 2300 |....@.8...@.$.#.|
0x0040 0600 0000 0500 0000 4000 0000 0000 0000 |........@.......|
0x0050 4000 0000 0000 0000 4000 0000 0000 0000 |@.......@.......|
0x0060 3002 0000 0000 0000 3002 0000 0000 0000 |0.......0.......|
0x0070 0800 0000 0000 0000 0300 0000 0400 0000 |................|
0x0080 a016 1200 0000 0000 a016 1200 0000 0000 |................|
0x0090 a016 1200 0000 0000 1d00 0000 0000 0000 |................|
0x00a0 1d00 0000 0000 0000 1000 0000 0000 0000 |................|
0x00b0 0100 0000 0500 0000 0000 0000 0000 0000 |................|
0x00c0 0000 0000 0000 0000 0000 0000 0000 0000 |................|
0x00d0 48f3 1300 0000 0000 48f3 1300 0000 0000 |H.......H.......|
0x00e0 0000 2000 0000 0000 0100 0000 0600 0000 |.. .............|
0x00f0 38f4 1300 0000 0000 38f4 3300 0000 0000 |8.......8.3.....|
0x0100 38f4 3300 0000 0000 404d 0000 0000 0000 |8.3.....@M......|
0x0110 5099 0000 0000 0000 0000 2000 0000 0000 |P......... .....|
0x0120 0200 0000 0600 0000 002b 1400 0000 0000 |.........+......|
0x0130 002b 3400 0000 0000 002b 3400 0000 0000 |.+4......+4.....|
0x0140 e001 0000 0000 0000 e001 0000 0000 0000 |................|
0x0150 0800 0000 0000 0000 0400 0000 0400 0000 |................|
0x0160 7002 0000 0000 0000 7002 0000 0000 0000 |p.......p.......|
0x0170 7002 0000 0000 0000 4400 0000 0000 0000 |p.......D.......|
0x0180 4400 0000 0000 0000 0400 0000 0000 0000 |D...............|
0x0190 0700 0000 0400 0000 38f4 1300 0000 0000 |........8.......|
0x01a0 38f4 3300 0000 0000 38f4 3300 0000 0000 |8.3.....8.3.....|
0x01b0 1000 0000 0000 0000 6800 0000 0000 0000 |........h.......|
0x01c0 0800 0000 0000 0000 50e5 7464 0400 0000 |........P.td....|
0x01d0 c016 1200 0000 0000 c016 1200 0000 0000 |................|
0x01e0 c016 1200 0000 0000 3457 0000 0000 0000 |........4W......|
0x01f0 3457 0000 0000 0000 0400 0000 0000 0000 |4W..............|
0x0200 51e5 7464 0600 0000 0000 0000 0000 0000 |Q.td............|
0x0210 0000 0000 0000 0000 0000 0000 0000 0000 |................|
0x0220 0000 0000 0000 0000 0000 0000 0000 0000 |................|
0x0230 0800 0000 0000 0000 52e5 7464 0400 0000 |........R.td....|
0x0240 38f4 1300 0000 0000 38f4 3300 0000 0000 |8.......8.3.....|
0x0250 38f4 3300 0000 0000 c83b 0000 0000 0000 |8.3......;......|
0x0260 c83b 0000 0000 0000 0100 0000 0000 0000 |.;..............|
0x0270 0400 0000 1400 0000 0300 0000 474e 5500 |............GNU.|
0x0280 de8b c1f3 7beb ac75 7d7f 2633 9cff 4dd3 |....{..u}.&3..M.|
0x0290 4ca1 c980 0400 0000 1000 0000 0100 0000 |L...............|
0x02a0 474e 5500 0300 0000 0800 0000 0100 0000 |GNU.............|
0x02b0 0000 0000 0000 0000 f303 0000 1500 0000 |................|
0x02c0 0001 0000 0e00 0000 0030 1044 a000 0201 |.........0.D....|
0x02d0 8803 e690 c545 8c00 c000 0800 0580 0060 |.....E.........`|
0x02e0 c080 000d 8e0c 0014 3400 8844 3208 2e40 |........4..D2..@|
0x02f0 8a50 342c 200e 2248 2684 c08c 0408 0002 |.P4, ."H&.......|
0x0300 020e a1ac 1a04 66c0 00c0 3200 c000 5001 |......f...2...P.|
0x0310 0081 089c 0a28 2028 2400 0420 5000 1058 |.....( ($.. P..X|
0x0320 80ca 4442 2800 0680 1018 4200 2040 8000 |..DB(.....B. @..|
0x0330 09d0 0851 8a40 1500 0000 0008 0000 1110 |...Q.@..........|
74149 preinst RET read 832/0x340
74149 preinst CALL fstat(0x3,0x7fffffffd040)
74149 preinst STRU invalid record
74149 preinst RET fstat 0
74149 preinst CALL
mmap(0,0x348d88,0x5<PROT_READ|PROT_EXEC>,0x2<MAP_PRIVATE>,0x3,0)
74149 preinst RET mmap 34368270336/0x800823000
74149 preinst CALL mprotect(0x800963000,0x1ff000,0<PROT_NONE>)
74149 preinst RET mprotect 0
74149 preinst CALL
__sysctl(0x7fffffffce50,0x2,0x8008220e8,0x7fffffffce48,0,0)
74149 preinst SCTL "hw.pagesize"
74149 preinst RET __sysctl 0
74149 preinst CALL
mmap(0x800b62000,0x6000,0x3<PROT_READ|PROT_WRITE>,0x12<MAP_PRIVATE|MAP_FIXED>,0x3,0x13f000)
74149 preinst RET mmap 34371674112/0x800b62000
74149 preinst CALL
mmap(0x800b68000,0x3d88,0x3<PROT_READ|PROT_WRITE>,0x1012<MAP_ANON|MAP_TYPE|MAP_PRIVATE|MAP_FIXED>,0xffffffff,0)
74149 preinst RET mmap 34371698688/0x800b68000
74149 preinst CALL close(0x3)
74149 preinst RET close 0
74149 preinst CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_ANON|MAP_TYPE|MAP_PRIVATE>,0xffffffff,0)
74149 preinst RET mmap 34366185472/0x800626000
74149 preinst CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_ANON|MAP_TYPE|MAP_PRIVATE>,0xffffffff,0)
74149 preinst RET mmap 34366189568/0x800627000
74149 preinst CALL sysarch(0x81,0x7fffffffd8a8)
74149 preinst RET sysarch 0
74149 preinst CALL open(0x80061b0b0,0<><invalid>0,<unused>0)
74149 preinst NAMI "/dev/urandom"
74149 preinst RET open 3
74149 preinst CALL read(0x3,0x7fffffffd898,0x8)
74149 preinst GIO fd 3 read 8 bytes
0x0000 f799 7052 87d2 fd5a |..pR...Z|

74149 preinst RET read 8
74149 preinst CALL close(0x3)
74149 preinst RET close 0
74149 preinst CALL mprotect(0x800b62000,0x4000,0x1<PROT_READ>)
74149 preinst RET mprotect 0
74149 preinst CALL mprotect(0x602000,0x1000,0x1<PROT_READ>)
74149 preinst RET mprotect 0
74149 preinst CALL mprotect(0x800820000,0x1000,0x1<PROT_READ>)
74149 preinst RET mprotect 0
74149 preinst CALL sigaction(SIGSYS,0x7fffffffda10,0)
74149 preinst RET sigaction 0
74149 preinst CALL getuid
74149 preinst RET getuid 0
74149 preinst CALL access(0x401a8e,0x1<X_OK>)
74149 preinst NAMI "/bin/sh"
74149 preinst RET access 0
74149 preinst CALL stat(0x401a8e,0x7fffffffd8c0)
74149 preinst NAMI "/bin/sh"
74149 preinst STRU invalid record
74149 preinst RET stat 0
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
74149 preinst CALL write(0x2,0x401b81,0xe)
74149 preinst GIO fd 2 wrote 14 bytes
"bash.preinst: "
74149 preinst RET write 14/0xe
74149 preinst CALL write(0x2,0x7fffffffb0b0,0x1d)
74149 preinst GIO fd 2 wrote 29 bytes
"cannot set close-on-exec flag"
74149 preinst RET write 29/0x1d
74149 preinst CALL write(0x2,0x7fffffffaff0,0x20)
74149 preinst GIO fd 2 wrote 32 bytes
": Inappropriate ioctl for device"
74149 preinst RET write 32/0x20
74149 preinst CALL write(0x2,0x800b66c43,0x1)
74149 preinst GIO fd 2 wrote 1 byte
"
"
74149 preinst RET write 1
74149 preinst CALL exit(0x1)

> and maybe the output from /proc/mounts

/dev/mirror/gm0s1a / ufs rw 0 0
devfs /dev devfs rw 0 0
/dev/mirror/gm0s1e /tmp ufs rw 0 0
/dev/mirror/gm0s1f /usr ufs rw 0 0
/dev/mirror/gm0s1d /var ufs rw 0 0
tank /tank zfs rw 0 0
tank/db-mysql /tank/db-mysql zfs rw 0 0
tank/db-postgres /tank/db-postgres zfs rw 0 0
tank/dns /tank/dns zfs rw 0 0
tank/ldap /tank/ldap zfs rw 0 0
tank/mail /tank/mail zfs rw 0 0
tank/mumble /tank/mumble zfs rw 0 0
tank/obj /tank/obj zfs rw 0 0
tank/skel /tank/skel zfs rw 0 0
tank/src /tank/src zfs rw 0 0
tank/syslog /tank/syslog zfs rw 0 0
tank/www-dispatch /tank/www-dispatch zfs rw 0 0
tank/www-php-misc /tank/www-php-misc zfs rw 0 0
tank/www-static /tank/www-static zfs rw 0 0
devfs /tank/dns/dev devfs rw 0 0
devfs /tank/ldap/dev devfs rw 0 0
devfs /tank/syslog/dev devfs rw 0 0
devfs /tank/mail/dev devfs rw 0 0
devfs /tank/db-mysql/dev devfs rw 0 0
devfs /tank/mumble/dev devfs rw 0 0
devfs /tank/www-dispatch/dev devfs rw 0 0
devfs /tank/www-static/dev devfs rw 0 0
devfs /tank/www-php-misc/dev devfs rw 0 0
proc /tank/mumble/proc proc rw 0 0
/sys /tank/mumble/sys sysfs rw 0 0
tmpfs /tank/mumble/lib/init/rw tmpfs rw 0 0
proc /tank/dns/proc proc rw 0 0
/sys /tank/dns/sys sysfs rw 0 0
tmpfs /tank/dns/lib/init/rw tmpfs rw 0 0
proc /tank/mail/proc proc rw 0 0
/sys /tank/mail/sys sysfs rw 0 0
tmpfs /tank/mail/lib/init/rw tmpfs rw 0 0
proc /tank/db-mysql/proc proc rw 0 0
/sys /tank/db-mysql/sys sysfs rw 0 0
tmpfs /tank/db-mysql/lib/init/rw tmpfs rw 0 0
proc /tank/db-postgres/proc proc rw 0 0
/sys /tank/db-postgres/sys sysfs rw 0 0
tmpfs /tank/db-postgres/lib/init/rw tmpfs rw 0 0
proc /tank/www-dispatch/proc proc rw 0 0
/sys /tank/www-dispatch/sys sysfs rw 0 0
tmpfs /tank/www-dispatch/lib/init/rw tmpfs rw 0 0
proc /tank/www-static/proc proc rw 0 0
/sys /tank/www-static/sys sysfs rw 0 0
tmpfs /tank/www-static/lib/init/rw tmpfs rw 0 0
proc /tank/www-php-misc/proc proc rw 0 0
/sys /tank/www-php-misc/sys sysfs rw 0 0
tmpfs /tank/www-php-misc/lib/init/rw tmpfs rw 0 0
devfs /tank/db-postgres/dev devfs rw 0 0

This is somewhat strange, I didn't expect my jail to see ALL the mounts.

> and of course "ls -al /dev/null"

crw-rw-rw- 1 root root 0, 19 Jun 29 04:11 /dev/null

> I don't have my jail in ZFS, but I guess devfs should be mounted at
> /path/to/jail/dev anyway, or else /dev/null could be missing, and get
> created as a regular file (which I also tried, and still couldn't
> reproduce this failure).

Yup, that's mounted.

cheers
--
Stefan Ott
http://www.ott.net/

"You are not Grey Squirrel?"

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Steven Chamberlain · External Since: Jan 19, 2006 Posts: 67

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.

> 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.

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.

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.

Regards,
--
Steven Chamberlain
steven.RemoveThis@pyro.eu.org

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Stefan Ott · External Since: Apr 04, 2009 Posts: 18

On Fri, Jun 29, 2012 at 1:41 PM, Steven Chamberlain 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?"

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Steven Chamberlain · External Since: Jan 19, 2006 Posts: 67

On 29/06/12 14:12, Stefan Ott wrote:
> Interesting. If you have a ideas / patches that I could try out I
> would be happy to.

You could rebuild bash with Jonathan Nieder's patch, and use it locally
http://lists.debian.org/20120627015952.GH7701@burratino

It would be nice to fix this, as bash is an essential package which I
guess would cause a problem during debootstrap. But fixing this isn't
release-critical, would require a freeze exemption, and it is extra
important that a fix wouldn't affect bash on other architectures.

In the longer term it would be better that our kernels and glibc can
implement the correct fix, and leave bash unmodified, as there are
probably other packages we don't know about with related problems.

Regards,
--
Steven Chamberlain
steven RemoveThis @pyro.eu.org

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Steven Chamberlain · External Since: Jan 19, 2006 Posts: 67

On 29/06/12 20:28, Robert Millan wrote:
> The problem is that userland isn't actually using O_CLOEXEC, because
> its declaration is missing in glibc headers. Actually it's already
> been reported: see #679198.

#679198 is this bug. Did you mean #635192?

In /usr/include/i386-kfreebsd-gnu/bits/fcntl.h :

> #if _POSIX_C_SOURCE >= 200809L
> #define O_TTY_INIT 0x00080000 /* Restore default termios attributes */
> /* Defining O_CLOEXEC would break kfreebsd 8.1, see #635192 */
> /* #define O_CLOEXEC 0x00100000 */
> #endif

So it is undefined on purpose?

Regards,
--
Steven Chamberlain
steven RemoveThis @pyro.eu.org

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Robert Millan · External Since: Dec 24, 2004 Posts: 293

reassign 679198 bash
thanks

2012/6/29 Debian Bug Tracking System :
> Processing commands for control.DeleteThis@bugs.debian.org:
>
>> reassign 679198 src:kfreebsd-9

This isn't a kernel bug. The kernel recognizes O_CLOEXEC properly
when userland uses it.

The problem is that userland isn't actually using O_CLOEXEC, because
its declaration is missing in glibc headers. Actually it's already
been reported: see #679198.

--
Robert Millan

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Robert Millan · External Since: Dec 24, 2004 Posts: 293

2012/6/29 Steven Chamberlain :
> #679198 is this bug. Â Did you mean #635192?

Yes, sorry.

> In /usr/include/i386-kfreebsd-gnu/bits/fcntl.h :
>
>> #if _POSIX_C_SOURCE >= 200809L
>> #define O_TTY_INIT Â Â Â 0x00080000 Â Â Â /* Restore default termios attributes */
>> /* Defining O_CLOEXEC would break kfreebsd 8.1, see #635192 */
>> /* #define O_CLOEXEC Â Â 0x00100000 */
>> #endif
>
> So it is undefined on purpose?

Correct. Although leaving it undefined might be worse than defining
it. E.g. consider programs doing:

/* use O_CLOEXEC if possible */
#ifndef O_CLOEXEC
#define O_CLOEXEC 0
#endif

fd = open (..., O_CLOEXEC);
// don't bother closing fd

But the decision is up to glibc maintainers.

--
Robert Millan

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Jonathan Nieder · External Since: Feb 26, 2009 Posts: 684

Hi Robert,

Robert Millan wrote:

> This isn't a kernel bug. The kernel recognizes O_CLOEXEC properly
> when userland uses it.
>
> The problem is that userland isn't actually using O_CLOEXEC, because
> its declaration is missing in glibc headers. Actually it's already
> been reported: see #679198.

When did O_CLOEXEC get involved? This report was about a use of
FD_CLOEXEC.

Thanks,
Jonathan

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Steven Chamberlain · External Since: Jan 19, 2006 Posts: 67

On 30/06/12 04:23, Jonathan Nieder wrote:
> When did O_CLOEXEC get involved? This report was about a use of
> FD_CLOEXEC.

I've been *assuming* (as the only thing that makes sense) the situation
is something like:

Enabling FD_CLOEXEC on an open fd was previously not implemented (in the
upstream kernel that we shipped with squeeze). So I think O_CLOEXEC is
considered as zero such that:

sink = open("/dev/null", O_WRONLY)

is taken by our kernels to imply O_CLOEXEC unconditionally. Any fcntl()
trying to enable it later would be a no-op.

But Stefan was trying to run a GNU/kFreeBSD userland on an upstream
FreeBSD kernel with FD_CLOEXEC support. This won't assume an implicit
O_CLOEXEC, yet our glibc still doesn't know how to enable FD_CLOEXEC and
returns an error.

So I suppose there might be a way to implement FD_CLOEXEC (to cater for
this special case) without implementing the O_CLOEXEC option yet. If
any of the above was a correct assumption.

Regards,
--
Steven Chamberlain
steven.TakeThisOut@pyro.eu.org

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Jonathan Nieder · External Since: Feb 26, 2009 Posts: 684

Hi,

Steven Chamberlain wrote:

> Hmmm, I can't seem to reproduce the problem here, in a kfreebsd-i386
> jail environment on a GNU/kFreeBSD (9.0) host. I had bash 4.2-2 already
> installed though.
>
> I'm trying "apt-get --reinstall install bash" or directly running
> /var/lib/dpkg/info/bash.preinst
>
> Here's a system call trace:
>
> 72202 bash.preinst CALL open(0x8049678,0x1<><invalid>1,<unused>0)
> 72202 bash.preinst NAMI "/dev/null"
> 72202 bash.preinst RET open 3
> 72202 bash.preinst CALL fcntl(0x3,<invalid=3>,0x8149)
> 72202 bash.preinst RET fcntl 1
> 72202 bash.preinst CALL fcntl(0x3,<invalid=4>,0x1<><invalid>1)
> 72202 bash.preinst RET fcntl 0
>
> Successfully opened /dev/null as fd 0x3. I assume that is fcntl()
> F_GETFL returning flags = 0x1 (which actually means FD_CLOEXEC was
> already set), then F_SETFL returning 0 = success.

That's the first difference from Stefan's trace, so let's start there.
/dev/null is opened with

sink = open("/dev/null", O_WRONLY);

O_WRONLY == 1, so this matches the open call in your trace. So far so
good. Then we try to set the FD_CLOEXEC flag:

if (sink >= 0)
set_cloexec(sink);

set_cloexec() is defined in terms of fcntl calls that get and set the
file descriptor's flags:

int flags = fcntl(fd, F_GETFL);
if (flags < 0 || fcntl(fd, F_SETFL, flags | FD_CLOEXEC))
die_errno("cannot set close-on-exec flag");

F_GETFL is 3, so fcntl is being called correctly. But why does
fcntl(F_GETFL) return 1 (== FD_CLOEXEC)? This looks like a bug. What
kfreebsd-image-(foo) package are you using, and at what version?

Puzzled,
Jonathan

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Steven Chamberlain · External Since: Jan 19, 2006 Posts: 67

Hi,

On 03/07/12 17:47, Jonathan Nieder wrote:
> F_GETFL is 3, so fcntl is being called correctly. But why does
> fcntl(F_GETFL) return 1 (== FD_CLOEXEC)? This looks like a bug.

That is what led me to assume that O_CLOEXEC might be defined as zero
when our kfreebsd-images are built (and hence FD_CLOEXEC set by
default). But I can't easily check this until I get a new kfreebsd-*
build environment set up.

This would explain why the problem only occurred in a jail on a FreeBSD
upstream kernel (which presumably doesn't do this, because their own
libc has the ability to set FD_CLOEXEC later on an open fd if requested).

Regards,
--
Steven Chamberlain
steven RemoveThis @pyro.eu.org

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Jonathan Nieder · External Since: Feb 26, 2009 Posts: 684

Steven Chamberlain wrote:

> That is what led me to assume that O_CLOEXEC might be defined as zero
> when our kfreebsd-images are built (and hence FD_CLOEXEC set by
> default). But I can't easily check this until I get a new kfreebsd-*
> build environment set up.

Debian's kfreebsd packages do not have any patches that intend to
change the meaning or value of O_CLOEXEC (nor any that mention it
in their description or patch text).

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org