Open andymotta opened 9 years ago
I think this is a bug. The connections should be terminated as soon as the log overlay is closed.
I ran into this problem today and I'm now unable to login via ssh on some nodes :(
Hey Julian, When that happens we've been restarting the fleet-ui container which releases the connections, has been the easiest workaround so far.
This works as workaround. Thank you for the tip!
Hello FleetUI Contributors,
First, thank you for your hard work and excellent product. Our developers really appreciate fleet-ui.
We noticed that journal -f ssh connections are not closed upon closing of the websocket. This leaves a number of ssh tunnels connected to the requested host, and eventually exhausts all available incoming ssh connections on said host.
Every time we bring up the journal these tunnels are created, and never terminated. If we look at the same journal 10 times we create 10 forever connections.
Inside container: 10932 13 root S 11820 1% 0% fleetctl --endpoint http://172.x.x.x:4001 journal -f dashboard@1.service 12750 13 root S 11820 1% 0% fleetctl --endpoint http://172.x.x.x:4001 journal -f dashboard@1.service
After a while (~104 requests to the same host), we are unable to ssh to the requested host at all: ➜ ~ ssh core@172.x.x.x ssh_exchange_identification: Connection closed by remote host ➜ git ssh core@172.x.x.x ssh_exchange_identification: read: Connection reset by peer
After bringing the socket-activated sshd service back up, we see this in the service journal: Jun 03 23:29:46 ip-172-x-x-x.us-west-2.compute.internal systemd[1]: sshd.socket: Too many incoming connections (64)
Is this because of the --follow nature of the connection?