Docker nproc limit has to be set, seemingly, too high in order for a container to run-CodePudding

I'm trying to debug a weird behavior of the image I don't own - GitHub repo with the image.

Running

docker run -it --ulimit nproc=100 --ulimit nofile=90:100 --network none --tmpfs /tmp:rw,noexec,nosuid,size=65536k --tmpfs /home/glot:rw,exec,nosuid,size=131072k --user=glot --read-only glot/python:latest /bin/bash

results in exec /bin/bash: resource temporarily unavailable.

However if we bump nproc to 10000 it suddenly starts working (for me even bumping it to 1000 results in the same error).

This image has no ps but from what I see in the proc folder, there are never more than 2 processes.

I'm not experienced with Linux and container limits, so any insights and comments are welcome.

P.S. A bit of background: This image serves as a sandbox for executing fleeting snippets of code, and nproc limit alleviates the fork bombing problem.

CodePudding user response：

from https://docs.docker.com/engine/reference/commandline/run/

For nproc usage Be careful setting nproc with the ulimit flag as nproc is designed by Linux to set the maximum number of processes available to a user, not to a container. For example, start four containers with daemon user:

docker run -d -u daemon --ulimit nproc=3 busybox top docker run -d -u daemon --ulimit nproc=3 busybox top docker run -d -u daemon --ulimit nproc=3 busybox top docker run -d -u daemon --ulimit nproc=3 busybox top The 4th container fails and reports “[8] System error: resource temporarily unavailable” error. This fails because the caller set nproc=3 resulting in the first three containers using up the three processes quota set for the daemon user.

CodePudding user response：

As the comment from @Philippe says - ulimit metrics are read per user system-wide.

The problem was that the user created for the image shared the same UID as the main user on the host, although with different username. When the limits were enforced for nproc in container the total number of processes for this UID was taken into the account (including all the processes from the local host user). And since this was ran on the desktop env with many running processes it is no surprise it broke the 100 hard limit (even 1000) on the number of processes.

Be careful with ulimits and UIDs, they are not encapsulated per container but rather shared system wide. And a user with different username but the same UID between a container and the host is treated as the same user when enforcing ulimits inside a container.