runsc-sandbox file descriptors keep growing since release-20250820.0 in specific conditions

[42wim]

Description

After updating to release 20250820.0 our PHP containers started to crash after some time because our open file limit of 1048576 was reached.

Some debug sessions later it seems that the containers with php-pecl-imagick installed were triggering the issue. We have a cronjob in those containers that do a php call every minute.

For some unknown reason for now the FDs that keep growing are those located in /usr/share/zoneinfo/

gvisor version prior to 20250820.0 doesn't have this issue.

I've been looking through the PR's between 20250811 and 20250820, maybe it's related to #11734

Steps to reproduce

Build a docker image from this Dockerfile, it must be actually build, just running almalinux:9 and then installing the packages will not trigger the issue.

Dockerfile:

FROM almalinux:9
RUN dnf -y update && dnf -y install epel-release && dnf -y install php php-pecl-imagick

Open 2 shells

First shell build and run the docker image.

docker build -t alma9test -f Dockerfile .
docker run -ti --rm --runtime runsc --name alma9test alma9test                                                                              

Go to the second shell and do a lsof of the running container and for grep havana, this should return nothing at the moment.

lsof -p $(docker inspect --format '{{.State.Pid}}' alma9test) -n|grep -i havana

Go to the first shell again where you have your alma9 shell in the container and run php command

php -r 'phpinfo();'

Go back to the second shell and run the lsof again, you should now see 1 result.

lsof -p $(docker inspect --format '{{.State.Pid}}' alma9test) -n|grep -i havana

will give something like

exe     607110 root  977r      REG               0,69       2416  35463423 /root/usr/share/zoneinfo/America/Havana

Go back to the first shell and run the php command multiple times

php -r 'phpinfo();'
php -r 'phpinfo();'
php -r 'phpinfo();'
php -r 'phpinfo();'
php -r 'phpinfo();'

Back to the second shell and you'll see multiple descriptors for this file open.

exe     607110 root  960r      REG               0,69       2416  35463423 /root/usr/share/zoneinfo/America/Havana
exe     607110 root  977r      REG               0,69       2416  35463423 /root/usr/share/zoneinfo/America/Havana
exe     607110 root 1077r      REG               0,69       2416  35463423 /root/usr/share/zoneinfo/America/Havana
exe     607110 root 1181r      REG               0,69       2416  35463423 /root/usr/share/zoneinfo/America/Havana
exe     607110 root 2657r      REG               0,69       2416  35463423 /root/usr/share/zoneinfo/America/Havana

runsc version

runsc version release-20250820.0
spec: 1.2.0

docker version (if using docker)

Client: Docker Engine - Community
 Version:           28.3.3
 API version:       1.51
 Go version:        go1.24.5
 Git commit:        980b856
 Built:             Fri Jul 25 11:36:05 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.3.3
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.5
  Git commit:       bea959c
  Built:            Fri Jul 25 11:33:27 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

uname

Linux cloud-1 4.18.0-553.71.1.el8_10.x86_64 #1 SMP Mon Aug 25 07:59:47 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

[ayushr2]

Thank you for the detailed reproducer and also bisecting the issue. Much appreciated!

[ayushr2]

I've been looking through the PR's between 20250811 and 20250820, maybe it's related to #11734

Your guess is correct. That commit implements inode sharing in our gofer client. We were leaking FDs for hard-linked files which were using a shared inode (from another dentry which was accessed earlier). We will be submitting a fix shortly.