Skip to content
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

Open
mattventura opened this issue Aug 23, 2023 · 4 comments
Open

Connections not closing, runs out of file descriptors #13

mattventura opened this issue Aug 23, 2023 · 4 comments

Comments

@mattventura
Copy link

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:

Aug 22 19:36:25 tobaru[538]: [2023-08-23T02:36:22Z ERROR tobaru::tcp] Accept failed: Os { code: 24, kind: Uncategorized, message: "No file descriptors available" }
Aug 22 19:36:25 tobaru[538]: [2023-08-23T02:36:22Z ERROR tobaru::tcp] Accept failed: Os { code: 24, kind: Uncategorized, message: "No file descriptors available" }
Aug 22 19:36:25 tobaru[538]: [2023-08-23T02:36:22Z ERROR tobaru::tcp] Accept failed: Os { code: 24, kind: Uncategorized, message: "No file descriptors available" }

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:

  • Timeout for old connections
  • Limit for connections, where new connections will close old connections once full
  • Option to have the service exit if this condition is hit so that it can be restarted automatically via systemd or others
@cfal
Copy link
Owner

cfal commented Aug 23, 2023

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 ss? (eg TIME-WAIT, CLOSE-WAIT)

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

@mattventura
Copy link
Author

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?

@mattventura
Copy link
Author

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.

@cfal
Copy link
Owner

cfal commented Aug 28, 2023

I'm not doing any TLS, just simple TCP+UDP. The connections I saw were in ESTABLISHED state.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants