[erlang-bugs] [erlang-questions] Process/FD leak in SSL R15B01

Loïc Hoguin <>
Thu Nov 1 12:38:18 CET 2012

On 10/30/2012 05:50 PM, Ingela Anderton Andin wrote:
> Hi!
> Loïc Hoguin wrote:
>> I don't understand why there's no timeout though. Wouldn't it make
>> sense to have a small timeout to avoid this and any related problem
>> entirely?
> Well yes and no ;) ssl:close should conceptually not fail so you should
> not need a timeout. The problem seems to be that be that the cleaning
> up code sometimes could cause a unforeseen hanging problem, as in the
> rabbitmq case. Although in your case it seems that the problem is
> something else, at least some of the times. Currently I am thinking that
> maybe the close function is incorrectly implemented and that it should
> utilize supervisor:terminate_child so that the OTP-supervisor will
> kill the process if it hangs in terminate. (It has a timeout) I will
> work on making sush a patch. I suppose in the meantime you could
> implement a timeout to ssl-close and verify that this timeout would
> solve your problem. As then my suggested way should solve it too just
> more OTPish and without the need of extending the API.

OK so perhaps I have done something wrong before when testing.

Today I can most certainly say that:

* This problem occurs *only* when ssl_connection processes receive 
'DOWN' in handle_info. The sockets for this problem stay in FIN2.

* Removing the call for recv/2 itself removes this problem entirely.

* There is another problem where processes get stuck elsewhere, which 
I'm going to try to investigate. Note that the sockets for this problem 

Loïc Hoguin
Erlang Cowboy
Nine Nines

More information about the erlang-bugs mailing list