https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412008-11-25T12:04:13Zlighty labsLighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=50992008-11-25T12:04:13Zdarix
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Invalid</i></li></ul><p>this is not really an issue. CLOSE_WAIT is a normal state in the life cycle.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=51002008-11-25T12:20:18ZGeorgH
<ul><li><strong>Status</strong> changed from <i>Invalid</i> to <i>Reopened</i></li></ul><p>True. But these CLOSE_WAIT connections stay open for hours, days, maybe forever. Which should not be part of the life cycle.</p>
<p>Maybe it has to do with the fcgi backends, but I'm quiet sure, there is some bug.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=51162008-12-01T14:27:40ZGeorgH
<ul></ul><p>I've tried to create a setup where I can reproduce the whole thing in a very simple setup. The point is, most of this is reproduceable, by setting up a machine with lighttpd and php via fastcgi. I've created a .php file containing only a sleep and then a phpinfo();<br />I'm accessing this page via wget, which times out right before the sleep finishes. Under these circumstances I can reproduce the CLOSE_WAIT state. <br />But I'm still not 100% sure, if this is exactly the same thing I get in the production evironment.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=51792008-12-23T13:02:00ZOlaf-van-der-Spek
<ul></ul><p>What is the problem?<br />You don't like CLOSE_WAIT?</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=51942008-12-29T10:07:18ZGeorgH
<ul></ul><p>The problem still is, that I've two nice webservers, one has 2090 and the other 1610 connections in CLOSE_WAIT state. The connections simply never close down :-(</p>
<p>I still hope to finde a solution to this phenomenon, which I think may come from the lighttpd-angle process.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=51962008-12-29T17:00:57Zstbuehler
<ul></ul>We found the same problem in lighttpd 1.5 with mod_upload_progress/mod_deflate, so we are interested in some details of your setup:
<ul>
<li>check the status page (mod_status) if there are connection in the "write" state which have written everything and match the CLOSE_WAIT connections; find out which modules handled these requests (fastcgi? upload_progress?).</li>
<li>are you using 3rd party patches like mod_deflate?</li>
</ul> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=51982008-12-30T10:05:44ZGeorgH
<ul></ul><p>The state seen with mod_status is "handle-req" on all the connections that stay open.<br />Nearly all requests are handled by fastcgi in my setup, as these machines only handle the dynamic generated traffic.<br />I'm not using mod_deflate on these servers. But as I see now, I've still activated mod_compress from some tests. But the cache dir is empty.</p>
<p>Perhaps the list of modules from mod_status config helps?</p>
<p>indexfile<br />access<br />alias<br />rewrite<br />fastcgi<br />status<br />compress<br />fastcgi<br />accesslog<br />dirlisting<br />staticfile</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=52012008-12-31T12:38:53Zstbuehler
<ul></ul><p>Strange - fastcgi is listed twice. if the requests hang in handle-req, it may be a problem with overloaded fastcgi backends.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=52022009-01-02T12:23:36ZGeorgH
<ul></ul><p>Thanks for the hint. fastcgi got really loaded twice, once through modules.conf and once through conf.d/fastcgi.conf. I fixed this.<br />Nevertheless, I still get fresh CLOSE_WAIT connections.</p>
<p>How exactly would I find out about a overloaded backend? As far as I see it, I still could handle more than 200 additional connections per backend:</p>
<ol>
<li>lsof -i :2000 | grep ^php5 | grep -v LISTEN -c<br />41</li>
<li>lsof -i :2000 | grep ^php5 | grep LISTEN -c<br />257</li>
</ol>
<p>I'll get back, when I've more information.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=57332009-03-23T15:42:54ZGeorgH
<ul></ul><p>As I could not find any solution to the problem, I've switched to version 1.5. Now the problem is gone for me.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=90562016-03-05T00:04:44Zgstrauss
<ul></ul><p>There probably should be a timeout for socket connections to backends when lighttpd is waiting to write/read to/from them. If there is a timeout on the backend, maybe lighttpd should set SO_LINGER enabled with timeout 0 before closing, so that TCP connection gets reset (TCP RST).</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=93182016-04-08T06:38:45Zgstrauss
<ul></ul><p><a class="user active user-mention" href="https://redmine.lighttpd.net/users/469">@GeorgH</a>: this might be fixed in a recent pull request:<br /><a class="external" href="https://github.com/lighttpd/lighttpd1.4/pull/53">https://github.com/lighttpd/lighttpd1.4/pull/53</a> improves the control flow logic in dynamic handlers, and so they will abort the connection to the backend after configured timeouts. (Note there is more work that needs to be done to add additional timeout configuration options.)</p>
<p>Any chance you can test this? (I realize that it is 7 1/2 years since you reported the issue, but figured I'd ask anyway :))</p>
<p>See also <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: handle-req time too long (Fixed)" href="https://redmine.lighttpd.net/issues/1149">#1149</a>, <a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: FastCGI performance on high load (Fixed)" href="https://redmine.lighttpd.net/issues/399">#399</a>, and <a class="issue tracker-1 status-10 priority-4 priority-default closed" title="Bug: handle-req timeout (Duplicate)" href="https://redmine.lighttpd.net/issues/647">#647</a></p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=93202016-04-08T06:38:59Zgstrauss
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" href="/issues/1149">Bug #1149</a>: handle-req time too long</i> added</li></ul> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=93222016-04-08T17:34:52ZGeorgH
<ul></ul><p>I'm sorry. I guess the system where this problem occurred doesn't exist anymore... for a few years now.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=93282016-04-10T04:31:44Zgstrauss
<ul><li><strong>Category</strong> set to <i>core</i></li><li><strong>Status</strong> changed from <i>Reopened</i> to <i>Fixed</i></li><li><strong>Target version</strong> set to <i>1.4.x</i></li></ul><p>I believe this issues has since been fixed in historical commits, potentially this one:<br /><pre>
commit d00e1e79b94e0f4da35292d2293595dac02993c7
Author: Stefan Bühler <stbuehler@web.de>
Date: Sat Feb 7 13:32:54 2015 +0000
[connections] fix bug in connection state handling
if a request was finished (con->file_finished = 1) and the state
machine was triggered, but the write queue was empty, it didn't
actually finish the request.
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2973 152afb58-edef-0310-8abb-c4023f1b3aa9
</pre></p>
<p>Other commits related to closing connections: svn r2636 (476c5d48) and svn r2645 (20c4cd55)</p>
<p><a class="user active user-mention" href="https://redmine.lighttpd.net/users/469">@GeorgH</a>: Thanks for your response. I was unable to reproduce your issue against tip of master given your description above using wget with timeout and FastCGI which waited a little bit longer. (Sorry, building 1.4.20 to attempt to repro would require quite a bit more work since I do not have a supporting toolchain available.) I tried running tip of master lighttpd 1.4.x with linux-sysepoll and poll backends, and tried modifying the size of the returned document. I could see with strace that larger than a page-size of 4k resulted in EPIPE when attempting to writev() to the wget client which had already closed the connection. For smaller documents, the writev() succeeded, and then the shutdown() failed with ENOTCONN, and then the connection was closed. It thankfully looks as if this bug was fixed in the past.</p>
<p>If anyone is still having this issue, please reopen ticket and test <a class="external" href="https://github.com/lighttpd/lighttpd1.4/pull/53">https://github.com/lighttpd/lighttpd1.4/pull/53</a><br />Thanks.</p> Lighttpd - Bug #1829: lighttpd leaves CLOSE_WAIT connectionshttps://redmine.lighttpd.net/issues/1829?journal_id=102322016-07-16T12:43:28Zstbuehler
<ul><li><strong>Target version</strong> deleted (<del><i>1.4.x</i></del>)</li></ul>