-
Notifications
You must be signed in to change notification settings - Fork 14
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
Connections not closing, runs out of file descriptors #13
Comments
how are you checking that there are only 20 connections on that port? for the 250+ TCP connections to/from tobaru, what state do you see them in when checking with a tool like also - do you have a server setup that forwards to both TLS and non-TLS servers? there was previously no timeout set for the peek TLS stage, which was just added. i'd recommend testing again at v0.9.0 which has quite a few fixes, but unfortunately requires a few config changes: https://github.com/cfal/tobaru/blob/master/UPGRADING.md |
Sorry, my notifications broke so I didn't see this until now. I'm not doing any TLS, just simple TCP+UDP. The connections I saw were in ESTABLISHED state. One thing that I don't see in the UPGRADING doc - do I need to change anything if I'm just using the URL configuration on the command line? |
Okay, I saw that the URL config no longer supports UDP, so I switched to YAML configuration and version 0.9.0. Still seeing the issue. |
if you're seeing it in ESTABLISHED state, that means that both sides of the connection (the proxy connection from you to tobaru, and the server connection from tobaru to your server) is still alive, and tobaru is behaving as expected. if either side of the pipe is not readable, the connection would be closed. |
I occasionally run into an issue where after running for a while, connections that haven't been cleanly closed from one end or the other accumulate, and eventually stops accepting more connections. I see a bunch of these in the log:
I think something is causing connections to not properly be cleaned up. For example, right now, the server running Tobaru is showing 250+ TCP connections to/from Tobaru, while the host that Tobaru is redirecting them to is showing only 20 connections on that port. Stopping the service for a few seconds and starting it again fixes the problem.
If the underlying problem can't be fixed, then there are several potential workarounds, including:
The text was updated successfully, but these errors were encountered: