Comment 1 for bug 1759440

I believe I figured out the problem. After running strace -f on while running apt-cache search, I saw a large amount of time spent doing this repeatedly:

[pid 202] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid 202] fcntl(13436, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid 202] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
[pid 202] fcntl(13437, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)

(with increasing fd numbers to fcntl()). It looks like apt-cache is trying to set FD_CLOEXEC on every possible fd.

I found this Ask Ubuntu question: https://askubuntu.com/questions/477757/why-is-apt-cache-so-slow

From a comment on one of the answers I did this:

echo 'APT::Architectures { "amd64"; };' > /etc/apt/apt.conf.d/01arch

Afterwards strace no longer shows the above behaviour. And apt is much faster:

root@snorri:~# docker run -it ubuntu:trusty /bin/bash
aroot@96c54574923b:/# time apt-cache search test

real 0m10.200s
user 0m0.644s
sys 0m9.532s
root@96c54574923b:/# exit
root@snorri:~# docker run -it ubuntu:trusty /bin/bash
root@9f97376b8dd2:/# echo 'APT::Architectures { "amd64"; };' > /etc/apt/apt.conf.d/01arch
root@9f97376b8dd2:/# time apt-cache search test

real 0m0.054s
user 0m0.028s
sys 0m0.008s

Would this be something we could fix in the image somehow?