[erlang-questions] Erlang node using ranch stops accepting SSL connections (SOLVED)

[Roger Lipscombe]

I tracked it down.

When setting up the listen socket, we set {keepalive, true}, AND we
set a bunch of raw options corresponding to TCP_KEEPIDLE,
TCP_KEEPINTVL and TCP_KEEPCNT.

Now, I _think_ I've got the correct numbers for these on the Mac, but
it appears that -- on the Mac -- these shouldn't be applied to the
listening socket. On Linux, they're inherited by the connected socket,
but don't appear to do anything to the listen socket. On Mac, they
seem to do things to the listen socket as well.

Or maybe not. Either way, we're now NOT setting any of the keepalive
options if os:type() =/= {unix,linux} and the server now continues to
accept connections.

On 15 April 2014 14:12, Roger Lipscombe <roger@REDACTED> wrote:
> I've got a problem where my Erlang node stops accepting SSL
> connections. I start it up, and it works fine for a couple of minutes,
> then it just stops accepting connections.
>
> By works fine, I mean:
> - It appears in "netstat -a | grep LISTEN"
> - "telnet localhost Port" works fine.
>
> After a couple of minutes, it simply stops accepting connections:
>
> - telnet gets connection refused; a simple Erlang ssl:connect gets
> {error, econnrefused}.
> - If I look in netstat, I no longer see the LISTEN entry.
>
> However, if I look in inet:i(), the socket is still shown as ACCEPT.
> This is unchanged from the working state.
>
> I'm using ranch 0.9.0; I think I've followed the instructions for
> supervising it correctly -- I call ranch:child_spec and add it to my
> supervisor. I _am_ creating the listen socket myself.
>
> If I enumerate processes, I still have plenty of processes sitting in
> ranch_acceptor:loop/3, in turn blocking in prim_inet:accept0/2.
>
> The owner process for the socket is still running. It's my supervisor,
> which is in turn supervising the ranch_listener_sup. I've verified
> this with sys:get_state(Pid).
>
> This is on Mac OS X (Mavericks), running Erlang R16B03 from Homebrew.
> The same code works fine on Ubuntu.
>
> Question: how do I go about figuring out who killed my socket?
>
> Regards,
> Roger.