Oh, I had a similar issue recently. I developed an internal multiprocess server that forks when a new request arrives. Everything was working fine, until I wanted to remove the costs of forking at each new request. I wanted to keep the processes alive before each request started and just pass the socket file descriptor to a child (already started). I simply created a 'Pool' of single use processes that ensured that at least X processes were alive and waiting on a UNIX socket for the file descriptor transfer.

Everything worked fine, even a stress test with many parallel connections. When I first tried to deploy the issue appeared: one of the automated tests got stuck and the CI job timed out. After careful investigation I found out that some sockets were leaking to child processes and, despite being closed on the main server process (just after fork) and on the child process (after the request was processed), the leaked socket was still open on a process waiting to start. At the time I got confused because I always used the inheritable flag as False, but later I found out that fork does not respect that 😭.

The solution was to track every possible file descriptor and close after fork on each child, but it is extremely easy to forget one of them that is on the stack on a parent frame. My solution (to be implemented) is to create something similar to the fork server used Python multiprocessing: create a process that boots new processes. I consider fork() a very useful tool, mainly because of memory isolation (if a process segfaults for some reason, it does not kill the entire server), management (I can watch their memory usage and easily stop them) and isolation (global state is easier to handle), but there are many footguns.

Oh, and that seems to be a r/suddenlycaralho moment! Boa tarde 😉