Bug#764204: apt-cache calls fcntl() on 65536 FDs
2015-05-20 18:16 GMT+02:00 Sebastian Boehm <sebastian@sometimesfood.org>:
> Hi,
>
> just looked into this, apparently the calls originate in the ExecFork
> function in apt-pkg/contrib/fileutl.cc, lines 760-792 (as of commit
> 15901516).
>
> Michael Vogt seems to have increased the number of file descriptors
> that are closed from 40 to sysconf(_SC_OPEN_MAX) in Git commit
> 61f954bf. (While the 65535 calls to getrlimit have been reduced to 1
> in the latest Git version, the fcntl problem remains.)
>
> The code fragment in question seems to have been introduced in the
> early days of apt (April 1999) by Jason Gunthorpe:
>
> commit 54676e1a82f400e37879bc931b6db0c13b8ebb3f
> Author: Arch Librarian <arch@canonical.com>
> Date: Mon Sep 20 16:53:38 2004 +0000
> Working apt-get source build stuff
> Author: jgg
> Date: 1999-04-20 05:02:09 GMT
> Working apt-get source build stuff
>
> // Close all of our FDs - just in case
> for (int K = 3; K != 40; K++)
> fcntl(K,F_SETFD,FD_CLOEXEC);
>
> I am not familiar enough with the apt codebase to understand the need
> to close all file descriptors. Would it be ok to only close the fds
> listed in /proc/self/fd/ as suggested by Julian Andres Klode?
>
Yes, of course it's possible to do this. It might be a bit more racy
in multi-threaded
code, but that's not really an issue.
I don't really see the performance issue here, though. I don't know
why the submitter thinks that there is a performance issue here. The
closing takes a few milliseconds. An apt-cache show runs in 0.040s
here, and has never taken longer for me. It's not even a performance
issue on slow ARM platforms. stracing the binary might give the
impression, because it has a significant overhead per-call.
So I'd prefer to just close this, as it's not worth the extra effort
to read out /proc/self/fd.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: