[hunchentoot-devel] CLOSE_WAIT and errcode 24 (too many files) when using https

[Hans Hübner]

Luke,

unfortunately, I cannot reproduce the problem in on my machine - I do not
see any open file descriptors left over after I connect to Hunchentoot
server with SSL using a non-SSL client, and when I connect to the same
server using a browser, I get an "Empty response" error.

In order to help you with this, I need you to isolate the problem further.
 Some ideas for debugging:

- Can you create a lingering file descriptor when you connect to your
server using telnet, then disconnect?
- Are the CLOSE_WAIT sockets actually connected to your monitoring service?
- Do you see the CLOSE_WAIT in lsof or in netstat?  I see it in netstat for
sockets that have been closed by the application, but for which the FIN TCP
packet has not been acknowledged by the client.  Note that CLOSE_WAIT
sockets are closed in the application and do no longer consume file
descriptors.  The final TCP handshake is performed by the kernel, and there
is nothing that Hunchentoot can do to make these sockets disappear.

I'm not saying that Hunchentoot has no bugs, but from your description, it
appears to me that your problem is related to your kernel configuration
(you're hitting the system-wide limit for sockets, not the process limit
for file descriptors).

-Hans


On Wed, Mar 27, 2013 at 1:12 AM, Lucas Hope <lucas.r.hope at gmail.com> wrote:

> Hi there,
>
> This is a bug report. I'm using Hunchentoot 1.2.2 from quicklisp. I
> encountered a server resource limit due to (I think) http connections on an
> https port.
>
> Cliffs notes:
>
> https server is not hanging up properly when a connection is attempted
> using normal http. This eventually causes the process to hit a kernel
> socket limit.
>
> Details:
>
> I recently upgraded my hunchentoot webserver from http to full ssl/https.
> The webservice runs on a dedicated port, and I left the port the same.
>
> We had a monitoring service running to check the server was alive. However
> the monitoring service wasn't updated to use https.
>
> So every half an hour or so, we got:
>
> [2013-03-26 06:49:26 [ERROR]] Error while processing connection: A failure
> in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X04B69660) (return
> code: 1). SSL error queue:
>
> error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
>
>
> Also, if I connect myself using http instead of https, the browser
> connection times out. The server certainly doesn't hang up instantly like
> I'd expect.
>
> Last night, my webserver listener threw a bsd socket error - code 24 (too
> many files). When I ran an lsof of the process, there were a large number
> of long term CLOSE_WAIT connections, which my internet research tells me is
> due to the server not closing connections properly. I think the connections
> piled up, and I thus hit the socket limit for that process.
>
> Anyone else have that issue? Is it an easy fix?
>
> Cheers,
>
> -Luke
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130327/805864a7/attachment.html>