Sysbox fails to apply soft file limit if the hard limit is capped

[ulfjack]

This is with docker-ce=5:28.2.2-1debian.11bullseye, sysbox=0.6.7.linux on a Ubuntu 24.04 box, although I also confirmed it with sysbox 0.7.0.linux. This works:

$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=12345:12345 ubuntu:latest cat /proc/1/limits
Max open files            12345                12345                files     
$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=200000:524280 ubuntu:latest cat /proc/1/limits
Max open files            200000               524280               files     

This doesn't work:

$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=524288:524288 ubuntu:latest cat /proc/1/limits
Max open files            1024                 524288               files     
$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=524289:524289 ubuntu:latest cat /proc/1/limits
Max open files            1024                 524288               files     
$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=12345:524289 ubuntu:latest cat /proc/1/limits
Max open files            1024                 524288               files     
$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=12346:524288 ubuntu:latest cat /proc/1/limits
Max open files            1024                 524288               files     
$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=524280:524288 ubuntu:latest cat /proc/1/limits
Max open files            1024                 524288               files     
$ docker run --runtime=sysbox-runc --rm -it --ulimit nofile=200000:524288 ubuntu:latest cat /proc/1/limits
Max open files            1024                 524288               files     

By comparison, running without sysbox applies the limit as expected:

$ docker run --rm -it --ulimit nofile=524280:524280 ubuntu:latest cat /proc/1/limits
Max open files               524280               524280               files

I can't find any reason why this would happen, and I looked through the sysbox source code, but that's the behavior I see on this machine.

[ulfjack]

We believe this is due to Golang doing bad things with ulimits. As a workaround, set the soft limit to a smaller value. Since this works in upstream Docker, I suspect that they had the same issue and implemented a fix that sysbox should also use.

[rogerhu]

So basically lowering the ulimit below the max of 524288 (as defined by systemctl show --property=DefaultLimitNOFILE) allows sysbox containers respect the --ulimit setting. If it's set to 524287 or lower, then problems occur because Golang wants to set this ulimit to lower to 1024 but set the rlim_max to the maximum.

Using strace, we can observe this behavior:

pushd $(mktemp -d)
sudo strace -f -ff -y -s 256 -o testing -p $(pidof containerd | tr ' ' '\n' | sort -n | head -n 1)

In a separate process on the same machine, we run different combinations of ulimit (524286, 524287, 524288). I use -ls -alc to make it more obvious in the strace where the prlimit calls are being made:

# vary the ulimit for 524286, 524287, and 524288
sudo docker run --rm --runtime=sysbox-runc  -it --ulimit=nofile=524287:524287 ubuntu:latest ls -alc

What we see for ulimits below 524288:

• Containerd forks the sysbox container and sets the process limit to 1024:

write(12<socket:[1061810]>, "{\"type\":\"rootfsReadyAck\"}", 25) = 25
read(12<socket:[1061810]>, "{\"type\":\"procReady\"}", 512) = 20
...
prlimit64(110262, RLIMIT_NOFILE, {rlim_cur=524286, rlim_max=524286}, {rlim_cur=524287, rlim_max=512*1024}) = 0

• Sysbox container is told to lower it's max (524286) via the --ulimit.

prlimit64(110262, RLIMIT_NOFILE, {rlim_cur=524286, rlim_max=524286}, {rlim_cur=524287, rlim_max=512*1024}) = 0

• Upon forking, Golang wants to set the ulimit to 1024. It also tries to set the rlimit maximum to be 524288, which results in an Operation not permitted error. The reason is that the sysbox container has lowered it already, therefore ignoring what Golang wants to do.

prlimit64(0, RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=512*1024}, NULL) = -1 EPERM (Operation not permitted)

I think it appears to be related to Golang v1.22 and v1.24 implicated in this change, which coincides with sysbox 0.6.7 and 0.7.0 upgrades. Golang sets and stores the maximum limit to 524288, but sysbox decides to change it. Upon forking, Golang tries to set it to 1024 but somehow still remembers it as 524288.

https://github.com/golang/go/blob/24ec7d2120d3d16b79cb2a7009a3e8025e4a2ce4/src/syscall/rlimit.go#L32-L45
https://github.com/golang/go/blob/24ec7d2120d3d16b79cb2a7009a3e8025e4a2ce4/src/syscall/exec_linux.go#L645-L660