Comment 4 for bug 1096975

For example in a devstack installation you can see the FD leaking issue. https://review.openstack.org/#/c/19145/

In your above example if the proxy-server wants to write anything to the stderr(fd=2) it will try to write to a pseudo terminal (/dev/pts/5).
Another possible issue is your ssh session which created the pty does not exists anymore, so nobody will see the messages and the used pty number and the associated resources will not be reclaimed by the system.

The usual advice for handling the inherited file-descriptors in the early init phase :
File descriptor 0-2: should be replaced by another safe fd like /dev/null . The related syscalls are: close(2), dup(2) , dup2(2) , dup3(2)
(Another possibility is redirecting them to a log file or just closing them)
File Descriptor 3-<max_fd> : should be closed:
The traditional solution is blindly call close(2) until getdtablesize(). Typically you have just 1024 File descriptor, but it could be increased to a higher number. AFAIK on Linux you do not have a well-known library call for listing the current process's open file descriptors, but you can do something similar to 'ls -l /proc/self/fd'.

You do not need to repeat these action after every fork, you juts need to do it the "main"/"mother"/"parent" swift-{proxy,container,account,object} process as early as possible.