[Buildd-tools-devel] Bug#486696: Bug#486696: File descriptor left open messages w/lvm snapshots

[Roger Leigh]

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.
> 
> joey at 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
> joey at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20090309/105453ac/attachment.pgp