Forums » Development »
[Abandoned] Interacting with fastcgi, remotely closed socket stay in CLOSE_WAIT
Added by gotham about 3 years ago
I've got lighttpd 1.4.28.
This version seem to have a bug when it interacts with fastcgi. When the remote host closes the socket, the local socket stays in the "CLOSE_WAIT" state forever. This is of course a big problem if "max connections" and "backlog" are both set to 1, because there can then be no new connections in the future.
I found a patch for this online, and applied it, but couldn't get the desired behaviour. The socket still stayed as "CLOSE_WAIT".
Has this bug been fixed in a later version, or perhaps in current SVN respository code?
Replies (4)
RE: Interacting with fastcgi, remotely closed socket stay in CLOSE_WAIT - Added by gstrauss about 3 years ago
Click the "Wiki" tab near the top of the page and look at "New Releases".
Latest lighttpd release is lighttpd 1.4.59. You're more than a few versions and over a decade out-of-date, as lighttpd 1.4.28 was released Aug 2010. There have been 2420 commits to the lighttpd git repository since lighttpd 1.4.28 was released.
RE: Interacting with fastcgi, remotely closed socket stay in CLOSE_WAIT - Added by gstrauss about 3 years ago
Click the "Issues" tab near the top of the page to see open issues in lighttpd.
Has this bug been fixed in a later version, or perhaps in current SVN respository code?
You're unlikely to get any further responses if you do not first make an attempt to read the documentation, and to test with the latest version.
RE: Interacting with fastcgi, remotely closed socket stay in CLOSE_WAIT - Added by gotham about 3 years ago
I'm dealing with code here that was written about 6 years ago by a person who has since left the project (let's call her Elena).
Elena took version 1.4.35 of lighttpd, and she heavily edited and augmented the 'connection' code to get it to write into a named FIFO pipe in the Linux file system. For example she took the following enum:
typedef enum {
CON_STATE_CONNECT,
CON_STATE_REQUEST_START,
CON_STATE_READ,
CON_STATE_REQUEST_END,
CON_STATE_READ_POST,
CON_STATE_HANDLE_REQUEST,
CON_STATE_RESPONSE_START,
CON_STATE_WRITE,
CON_STATE_RESPONSE_END,
CON_STATE_ERROR,
CON_STATE_CLOSE
} connection_state_t;
And extended it with:
CON_STATE_READ_CHUNKED
Elena's modified version of 1.4.35 works very well except for one small issue - When the client closes the TCP connection, lighttpd's server socket stays forever in the state "CLOSE_WAIT". This is a big problem because it means I get an accumulation of sockets. Also, if I set "server.max-connections=1", then it means I can't accept any other future connections because the first one hasn't closed yet.
The code for lighttpd has changed significantly since 1.4.35, and so I can't just take Elena's code changes and apply them to the latest version of lighttpd.
Instead, what I need to do is find the exact SVN revision in which the "close_wait" bug was fixed, and then merge this revision with Elena's code. I have looked at SVN revisions 2636 and 2645, but both of these revisions have already been applied to Elena's code.
Can anyone please help me find the revision in which the "CLOSE_WAIT" bug was fixed?
RE: Interacting with fastcgi, remotely closed socket stay in CLOSE_WAIT - Added by gstrauss about 3 years ago
Instead, what I need to do is find the exact SVN revision in which the "close_wait" bug was fixed
That's quite an assumption you are making.
Can anyone please help me find the revision in which the "CLOSE_WAIT" bug was fixed?
You have thus far not demonstrated much skill in the way of using a basic website, such as using the "Search" box in the upper-right of this page to search for "CLOSE_WAIT".
lighttpd 1.4.35 was released in Mar 2014. If your company would like to pay for support for this specific project, please send an RFP to my email, including a budget estimate. If you think this is only 10 mins of work, then you are going to be disappointed.