Bug#639897: Please don't check /proc/mounts
On Thu, Sep 01, 2011 at 08:54:26AM +0200, Sandro Tosi wrote:
> Hi,
>
> On Wed, Aug 31, 2011 at 16:38, Julian Andres Klode <jak@debian.org> wrote:
> > On Wed, Aug 31, 2011 at 03:20:13PM +0200, Sandro Tosi wrote:
> >> Package: apt
> >> Version: 0.8.10.3
> >> Severity: normal
> >>
> >> Hello,
> >> I found this behavior:
> >>
> >> # apt-get --version | head -n1
> >> apt 0.8.10.3 for amd64 compiled on Apr 15 2011 07:35:31
> >> # strace apt-get autoremove 2>&1 | grep mounts
> >> open("/proc/mounts", O_RDONLY) = 22
> >>
> >> (it also happens on the sid vrsion).
> >>
> >> This poses a problem when a system has a lot of mounts and so /proc/mounts is
> >> really big.
> >>
> >> I remember I had fixed a similar behavior on lenny by upgrading libselinux1 to
> >> the squeeze versions, but now I'm on squeeze and I see it again, and I don't
> >> see a trace of libselinux be linked into apt.
> > It's not APT either, APT wants to read /etc/mtab and then /proc/mount because
> > cdromutl.cc misses the "s". The complete source code does not contain the
> > word "mounts", but that's a different bug (and once fixed, makes this bug
> > apply to APT itself, instead of something APT uses).
>
> Ehm... I don't think I can parse this paragraph :)
(a) APT sometimes needs to get the partition table and looks for /etc/mtab
and /proc/mount, the latter missing the "s" at the end. This should
be fixed -- and once it is, APT would read the file itself as well
in addition to the indirect use we currently have.
(b) "bzr grep mounts" does not produce any result in the APT repository,
so APT clearly does not open the file itself.
>
> > While we need to find the mount point of a device something and might do
> > something like this when using the cdrom acquire method, this specific
> > case is not caused by APT itself, but rather by a lower library,
> > as far as I can tell (the cdrom method is a child process and thus
> > not catched by strace anyway, so it's not what you got).
>
> I probably agree here, but I can only exploit this behavior with apt,
> that's what weird.
>
> > Furthermore, I cannot reproduce this at all. What might be helpful
>
> Oh really? I had no problem seeing this on our squeeze servers and on
> my sid workstation, and I don't think I did anything unusual.
Mount points somewhere on /var, /var/cache, /var/cache/apt/,
/var/cache/apt/archives? Not 64-bit?
>
> > would be a backtrace for the open call, so we know why it
> > happens (ltrace -S e.g. traces both library and system calls, and
> > with -C you get readable C++ names).
>
> I've run ltrace with -S -C options on "apt-get autoremove" on my sid
> workstation, and you can find the (big) output at [1].
>
> [1] http://people.debian.org/~morph/639897_ltrace_S_C.out.bz2
This tells me that statvfs64() in libc6 reads it, and
reading the eglibc code confirms this, it's read in:
sysdeps/unix/sysv/linux/internal_statvfs.c
It needs to do this to get the mount options to report them
back. We only want the free space, though.
One option we have (at least on Linux) is to use statfs()
instead, as statfs() reports only a subset of statvfs()
information, and does not need to read /proc/mounts. At
least LSB has deprecated this, though, and recommends
the POSIX statvfs() interface we currently use.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: