[root@8cc0854b304d /]# time fakeroot -- sh -c 'echo hello'
hello
real 13m23.007s
user 0m0.027s
sys 0m0.008s
This image is partially affected by a bug quirk in faked, where it tries to close all available file descriptors.
When building packages, makepkg runs fakeroot, which in turn spawns faked, which dives into a loop, proportional to the value of ulimit --nofile. A possible default amount of those in my case was 1073741816:
root@photon # docker run --rm ghcr.io/greyltc-org/archlinux-aur:yay sh -c 'ulimit -n'
1073741816
root@photon # ulimit -n
1024
root@photon # docker run --rm archlinux sh -c 'ulimit -n'
1073741816
root@photon # docker run --rm alpine sh -c 'ulimit -n'
1073741816
Solution to this issue is mentioned here, it suggests setting ulimit yourself. Possible ways are:
- In run command:
docker run --rm --ulimit nofile=1024:10240 -it ghcr.io/greyltc-org/archlinux-aur
- In build command:
docker build --ulimit nofile=1024:10240 .
- In docker-compose:
.services.myservice.ulimits.nofile = "1024:10240" (I can't find how to set this for build stages in docker-compose)
- For the daemon:
systemctl edit containerd.service (and, probably, the same for docker.service)
[Service]
LimitNOFILE=65536
Note, that setting limits for daemons is not recommended for performance reasons.
To verify, that this works I've used this dockerfile:
FROM ghcr.io/greyltc-org/archlinux-aur
RUN timeout -v 30 aur-install kickstart-git
Where kickstart-git is one of the packages I found that has minimal dependencies almost no install steps. It hangs (and fails) after ==> Entering fakeroot environment... without ulimit, and succeeds with limits set.
I haven't seen that many mentions of this quirk. Probably, most of docker users do not encounter this problem because they do not use fakeroot/fakechroot in the building process. This image is the notable exception. So, maybe, mentioning this mitigation in the README would save some people a couple (dozens) of minutes of research?
I'd recommend adding a troubleshooting section with something like
docker run --rm ghcr.io/greyltc-org/archlinux-aur sh -c 'time aur-install kickstart-git'
# (should take about 10-20 seconds)
to see if docker installation is affected by this, and one example to set ulimits if it's needed.
This image is partially affected by a
bugquirk infaked, where it tries to close all available file descriptors.When building packages,
makepkgrunsfakeroot, which in turn spawnsfaked, which dives into a loop, proportional to the value ofulimit --nofile. A possible default amount of those in my case was 1073741816:Solution to this issue is mentioned here, it suggests setting ulimit yourself. Possible ways are:
docker run --rm --ulimit nofile=1024:10240 -it ghcr.io/greyltc-org/archlinux-aurdocker build --ulimit nofile=1024:10240 ..services.myservice.ulimits.nofile = "1024:10240"(I can't find how to set this for build stages in docker-compose)systemctl edit containerd.service(and, probably, the same fordocker.service)Note, that setting limits for daemons is not recommended for performance reasons.
To verify, that this works I've used this dockerfile:
Where
kickstart-gitis one of the packages I found that has minimal dependencies almost no install steps. It hangs (and fails) after==> Entering fakeroot environment...without ulimit, and succeeds with limits set.I haven't seen that many mentions of this quirk. Probably, most of docker users do not encounter this problem because they do not use fakeroot/fakechroot in the building process. This image is the notable exception. So, maybe, mentioning this mitigation in the README would save some people a couple (dozens) of minutes of research?
I'd recommend adding a troubleshooting section with something like
to see if docker installation is affected by this, and one example to set ulimits if it's needed.