Need a good way to kill off ET sessions
Closed this issue · 8 comments
I have read #225 and #222 which both say "use tmux/CC/htm" but that's unsatisfactory because
- tmux is a bit obnoxious it interferes with scrolling and such (a big reason one uses ET)
- tmux+CC requires a very specific terminal program which only runs on MacOS
- htm (most un-searchable name ever??) seems to require a specific terminal program which IS cross platform but... may not be everyone's cup of tea
Session resumption after client restart is a nice-to-have feature, but orphaned session destruction is vital -- without it, ET is really not very usable since one's server will eventually accumulate more and more orphaned sessions running who-knows-what and buffering their output. Furthermore, session killoff shouldn't require any rocket surgery (the way session resumption would). My workaround for now is killall etterminal but that's crude and clumsy and kills ALL sessions not just orphaned ones.
But how to know when a session is orphaned?? Well, one could have a way to list all sessions showing their (self reported) originating hostname, username, established time, time since last traffic, currently running command, etc. and then kill them off selectively. That would require some sorta whiteboard where those things are written down but that can be implemented.
ALSO if you have such a list somewhere and it includes a unique identifier of originating host (nodename + machineid?) and the client PID on that host, then when a new connection shows up from the same host, there could be a little back-and-forth where the server sends it the list of other connections from that host, and the client checks if those PIDs are even still running et processes, and if not says to kill 'em off.
If the objection to implementing this is lack of time, that's understandable, but maybe we can keep the feature request open and if some kind soul decides to take it on (maybe even me!!) they can look here for design pointers? Or if you architecturally object to such a thing given that theoretical workarounds (even if limited) exist, that's good to know also.
A lot of what you are describing is solved by -x, but I understand that -x limits you to one remote session per user/host pair.
The bigger problem is, how would the server tell the client that information? Mosh can show that information because they are in charge of the terminal (also the reason you lose your scrollbars). ET can't really display anything, but it could run commands when you connect.
Yeah, should have mentioned that et -x is mostly isomorphic to killall etterminal. (Now I'm curious to look internally and see if it looks through the process table, or if there's already a whiteboard of running server terminals...)
I was thinking there'd be two channels. One is you'd have some little utility program / subcommand so you could run et ls and it would list sessions on that server, and you could say et kill [session number]. (Maybe that's a bad interface in case you have hostnames ls and kill, but you get the idea.)
The other is that the same data would get sent from server to client at handshake time, and the client would send back a thing saying to kill off any sessions that are definitively dead from that particular client, and all of this would happen before actually starting the connection proper, as a way to deal with the reboot situation automatically.
Finally, there could be a configurable timeout, and any session that hadn't had any contact with its client in that long would get killed off. I'm sure some people won't want any timeout, but I would totally take a day or so for my common use cases.
The configurable timeout sounds pretty simple. The etterminal processes could fetch it from the cfg and kill themselves so no communication is even needed for that one. Happy to review PRs and answer questions.
Yep, the timeout would be a good start. Any guidance where you'd go about adding that?
Right here: https://github.com/MisterTea/EternalTerminal/blob/master/src/terminal/UserTerminalHandler.cpp#L71
You would read the cfg file for the timeout (look in the code for .cfg to see how to read the file), then keep the latest time of activity. If, in the while(true), you elapse the timeout without any new activity, break out of the loop and let the terminal process exit.
@egnor Do you have any updates on this?
I do not! Are other people excited about this too?
@egnor I already have too much on my plate with my other open-source projects, so I'm unlikely to implement it (at least for now).