TIME_WAIT consumes file descriptors?

Question

In many TCPIP and Web tunning guide, recommends increasing max number of file descriptors when getting the error "Too many open files"

but, i can't see TIME_WAIT in outputs of "lsof -i"

Does anyone know that TIME_WAIT consumes file descriptors? or not

Solution 1

The file descriptor is used by application to read/write from the socket. Thus if the application call close(), the file descriptor is immediately released.

On the other hand, if the application call shutdown(), file descriptor will remain effective so that application can still read/write from/to the socket.

Quotes from https://oroboro.com/file-handle-leaks-server/:

Myth: Sockets in TCP TIME_WAIT are holding file handles Hostage

When you close a TCP/IP socket the operating system does not release the socket right away. For complex reasons, the socket structure must be kept out of circulation for a few minutes because there is a small chance that an IP packet may arrive on that socket after it has been closed. If the operating system re-used the socket then the new user of that connection would have their session affected by someone else’s lost packets.

But this does not hold a file handle open. When you close the socket’s file descriptor, the file descriptor itself is closed. You will not get the “Too many files open” error. If you have too many sockets open, then your server may stop accepting new connections. There are ways to deal with that ( allowing sockets to be re-used, or lowering TCP TIME_WAIT )- but raising the file handle limit isn’t one of them.

Myth: It takes time for file handles to be released

This is related to the TCP TIME_WAIT myth. The mistaken belief that when you close a file handle that you must wait some time for the operating system to release the handle.

Closing a file handle will call into whatever os method releases the resource, and the OS will release that resource either immediately, or sometimes later as in the case with sockets, but close() will release the file handle in the file handle table immediately. Your process is in complete control of its file handle table, and doesn’t need to wait for anything to free a slot in its own file descriptor table.

Solution 2

TIME_WAIT is a TCP state and doesn't consume file descriptors persay. However the sockets in TIME_WAIT will consume file descriptors. A socket is a file like just about everything else in unix. If this is Linux you can tune the expire time of sockets (how long they are in time wait) as well as enable socket recycling in /proc/sys/net/ipv4/.

Two items of particular interest are probably:

sysctl -w net.ipv4.tcp_tw_recycle=1
sysctl -w net.ipv4.tcp_tw_reuse=1

As always, test these beforehand if you can.

Comments

[jyz]

is it possible to restore a "TIME_WAIT" connection to "ESTABLISHED" again?

[James Cape]

AFAIK, the side of the connection that did a close() on the socket goes into TIME_WAIT on that socket to ensure that the the other side receives the close()/FIN. If the peer doesn't see the FIN, the side calling close() should retransmit it. So my understanding is that the answer is "it shouldn't be possible, no."