>> Thanks for your suggestion Alex, but I'm using the non-blocking API
>> as you advised: I call libssh2_session_free with the same paramerters
>> either it returns something different than EAGAIN, or the timeout
>> In my case, when the remote device goes down ungracefully, any amount of
>> seconds wait will result in timeout: I even tried 15 seconds. I suppose
>> resource destruction should be instant. It looks like libssh is waiting
>> something inside there, whereas I want it to just free all resources...
> That make it sound like a bug. Can you tell us how to repeat this
> you single-step through the code and see where the problem lies?
> Which libssh2 vesion are you using?
Hi Daniel, well, here is why it happens: on session free it attempts to
send eof when freeing a channel, and performs transport_read, which returns
EAGAIN and propagates it up the stack. The problem as I see it is that the
current session and channel closing functions try to do it gracefully by
means of notifying the server side about their intention to quit the
In my scenario, which can be reproduced by simply unplugging ethernet cable
from the device running sshd, any attempt to perform communication on the
channel will result in EAGAIN, cause the network stack sees the network is
not ready, and SIGPIPE won't come up in the next hour or so. So knowing
that the connection is now zomby, I want to have a means to destroy the
session and channel resources without trying to communicate it to the other
party. Such function would not return EAGAIN in any case, cause it is just
about freeing structures...
So far I just leave the session open and close the underlying socket. Of
course, I don't make any calls to libssh2 on that session, cause that would
result in a delayed crash, but anyway it is better than the sockets leak. I
run libssh2-1.4.3. Again, thanks for the great library!
Received on 2013-03-04