On Tue, Jun 17, 2008 at 02:38:50PM -0400, Joey Hess wrote: > Package: schroot > Version: 1.2.0-1 > Severity: minor > > These messages were previously mentioned in #379671, but I'm seeing them with > current unstable. > > j...@kodama:~>schroot -c sid > File descriptor 3 left open > File descriptor 4 left open > I: [sid-6a6a7764-9640-47e7-86d0-a05f1c305384 chroot] Running login shell: > ‘/bin/zsh’ > 14:37:10 up 1 day, 21:08, 0 users, load average: 0.39, 0.53, 0.58 > j...@kodama:~> > File descriptor 3 left open > File descriptor 4 left open
Sorry for the long delay in continuing to follow this up. I've checked all the code, and there are these possibilities for leaking file descriptors: * syslog closelog() is called after every top-level fork() so this won't leak - there won't be any syslog fd open before an execve(). * cctty A C++ iostream wrapper around /dev/tty. This is created with FD_CLOEXEC, so can't leak either. It is automatically closed on execve and program termination (object destruction). * other standard file I/O using regular open()/close() This is generally wrapped using the __gnu_cxx::stdio_filebuf stream buffer. However, we only ever do this sort of I/O in a local open-lock-read/write-unlock-close sequence within a single function. There's no reason for any of this code to leak fds; the iostream wrapper even automatically closes the fd on destruction, so it's also exception safe. At least in theory; it's potentially possible an older libstdc++ wasn't cleaning up the fds; I did read the source back when the problem was first reported to verify it was calling close() correctly. I'll double check the gcc-4.3 sources. I've tested the current git with an lvm-snapshot chroot and I can't reproduce the failure. WRT leaking fds, there are no signigicant changes compared with the version in stable/testing/unstable which would make me believe that the older version behaves any differently. It's been pretty much frozen during the Lenny freeze. Would it be possible to verify that this is still a problem on a current stable/testing/unstable system (it's all the same version)? If it's still occuring, I'd very much like to track down the source of the fd leak. To do that, I would suggest running in a debugger, breaking on fork() and then using lsof or /proc to look at what files the schroot process actually has open. At fork() time, it should only have stdin, stdout, stderr, /dev/log and /dev/tty open. If you break on the subsequent exec, the syslog fd should be closed. And, after the exec completes, /dev/log should have been closed by the kernel. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
