Test failures seem unrelated, restarted the failed tests

In fact, we will close all unneeded fds before execve the container process, so it won’t cause resource leaks. But we shouldn't rely too much on this fallback logic. Thanks.

In fact, we will close all unneeded fds before execve the container process, so it won’t cause resource leaks.

This is wrong, because the function sendContainerProcessState is called in runc main process, and if we start a large number of containers concurrently — especially those without detach — it can result in a large number of open FDs being held in the runc parent process. Furthermore, these FDs may maintain long-lived connections to the seccomp listener, increasing the risk of resource exhaustion.

@astrawind Could you help to open backport PRs for release-1.2 and release-1.3?

@lifubang

This is wrong, because the function sendContainerProcessState is called in runc main process

Exactly, this should be in the parent and not affect the container process.

This is wrong, because the function sendContainerProcessState is called in runc main process, and if we start a large number of containers concurrently — especially those without detach — it can result in a large number of open FDs being held in the runc parent process. Furthermore, these FDs may maintain long-lived connections to the seccomp listener, increasing the risk of resource exhaustion.

Not sure I follow, what is the issue? If we start a lot of containers, then we will start the runc parent binary a lot of times, right? I'm not sure I follow your concern here. Can you please elaborate?

If we start a lot of containers

concurrently

@lifubang yeap, if we start lot of container concurrently, what is the issue? I don't see how it can be a large number of open fds, as each container start creates a new process.

what is the issue?

Without this patch, runc will not release the socket connection after calling syncParentSeccomp (which occurs before the container process starts). If all processes reach this stage simultaneously, it could result in a large number of open file descriptors on the host. This issue becomes particularly significant when a TTY is used for communication with the container, as the associated socket connections may remain open indefinitely until the user logs out of the container.

@lifubang I don't see it, what am I missing?

The process that has this connection open dies when the container starts. And each process won't have more than 1 connection for this. How is it that if a tty is used any of this changes? And what is the issue if several process on the host have one connection open? This connection might be closed when the process dies, but the concurrency is the same if you time it enough to be opened at the same time, even if we do the close.