-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HAPServer doesn't close sockets and eventually hits OS limit #145
Comments
Hi and thanks for the report. I will take a look a this in the following days |
I confirm that I see the issue as well. However, I don't know how this happens yet - I suspect the handler doesn't |
More on that: I have 36 threads running. There is one for the server, one for the event thread, 3 for accessories and whatever asyncio has (say 10-15 that actually do something). Each handler spawns another thread and stays alive until the socket is closed. So probably the handlers are stuck waiting on a closed socket. |
Narrowing down: It appears that a HAP socket thinks its connected and is blocked on recv (see Frame 12 at the bottom of the snippet)
|
I think I got it - The HAPSocket inherits and is initialised from a socket to implement the custom HAP crypto. During initialisation something is not copied properly as the socket is both in CLOSE_WAIT and blocked in recv. I don't know the exact issue though. So instead of subclassing I went another way (a Proxy pattern) and the issue is gone now. I will submit the fix tomorrow. |
Not fully fixed - I hope to fix it soon. |
Apparently the object created by makefile (SocketIO) uses a member of the socket - I currently fixed this by defining the same property in HAPSocket and proxying all calls to it, but I will ry to unit test this so we really know we are done here. |
Apparently the object created by makefile (SocketIO) uses a member of the socket - _io_refs, directly. Since it assigns to it, the call does not go through __getattr__ and ends up in HAPSocket instead. This change also adds tests which cover the above case.
Added a simple test to check for the issue. Also had the fix running for 1 hour with 2 iOS clients. |
still having the issue of Homekit intermittent problem with 'No response' on IOS devices :-( |
Also have similar issues. I noticed that sockets count is fine now but
threads count grows until python fail to create new one. It is also
possible because of my custom devices, but they are pretty simple.
On Sat, 23 Feb 2019 at 19.43, alessandrocolos ***@***.***> wrote:
still having the issue of Homekit intermittent problem with 'No response'
on IOS devices :-(
Running one raspberry pi 3, hassio 0.88.1 (latest)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#145 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADO3kH3qvMxWc-p9ZAw4DiGUmDLmY0SVks5vQX22gaJpZM4WEsi7>
.
--
Best regards
Andrey Yanovsky
|
After running hap for several days my system hit the limit of listen sockets (128 default on raspbian). Most of them in CLOSE_WAIT, so hap-client sent FIN but hap-server code didn't handle it correctly (it suppose to close socket).
Briefly looked into hap_server.py, can't see how is this situation handled
The text was updated successfully, but these errors were encountered: