Forced to restart client when shell session become unresponsive

[Barbarisch]

Describe the bug While interacting with a shell the command line becomes unresponsive. There is no way to exit the shell context so I am forced to restart the entire client. The amount of time I can keep a shell active is about 20 to 30 minutes (or less when in multiplayer mode).

To Reproduce

1. Enter shell from active session
2. Run commands that are long running or produce a lot of output (while other multiplayer sessions are also using shells)

Expected behavior Shell timeout notification or response to some sort of key press that allows me to continue interacting with a good sessions

Desktop (please complete the following information):

• OS: Kali Linux 2021.1
• Client v1.4.14

Additional context I am guessing there is some unreliability in the network comms. In most cases I can confirm that the shell process is dead and just start up a new shell. In a few cases the shell is still running just not responsive and I can manually kill it after the fact. The fact that in most cases the session for the actual callback is still good hints that there is some infinite loop in the comms channels that prevent it from continuing to interact with the process or detect that it is dead. Either way I would think that just being able to back out of the shell context would allow me to more easily recover from a hanging shell without having to completely restart my sliver client.

[moloch--]

We're award of this issue, and it's actually a deceptively hard bug to fix because there's no good way to do a cross-platform read() cancel.

[Barbarisch]

I guess I am not understanding the problem then. Because as far as I can tell, key presses are still getting captured, and being sent through, its just since there is no return (because of a dead/hanging process on the other side) there is no "actions" being taken. I guess I thought since key input is being captured and passed along that there should be some logic in place to check the input before passing it on to the shell. I will look at the code more carefully. Thanks