Exit gotty server when connection is closed?

[yudai]

Exit gotty server when connection is closed?

[yudai]

Hi, thank you for the feedback and proposal.

To implement your requirement, we need figure out what should happen to the other clients when a client exits its command. Gotty forces all clients to drop their connections, or just stops accepting new clients and waits for the other clients to complete their commands?
I assume that what you want to achieve needs another option to limit the max connection number like -n 1.

If you can write a script for your garbage collection, using a shell script might be a better way.

#!/bin/sh
ssh [email protected]

# do some garbage collection
rm something

then run gotty -w your_script.sh

[ahmetb]

@yudai by garbage collection I actually just meant collecting the gotty server itself. If gotty dies when ssh user@host command above exits, then my process can realize "ok, the user has quit".

Hypothetically, let's say I am building a web service where you give me your hostname, username, password/SSH key and I'm creating a gotty server (streaming a SSH client) and giving you http://gotty-host:ip of the SSH session. Let's say you connected to here, and you're done, you type exit ––now what I expect gotty to do is also exiting, so that I can destruct http://gotty-host:ip and next time you want to use the service again, you come to my server and I give you another http://gotty-host2:ip2.

When the process quits, yes, it makes sense to drop all client connections to gotty in this scenario. However I don't think I would need a max connection count here.

In a nutshell, if the exec-ed process exits, gotty probably should exit, too (instead of re-exec'ing) the process. I think we can achieve this simply by a --quit-if-command-exits flag and just os.Exit(0)ing when the executed process quits.

[yudai]

How about a option like --one-time? With this option, gotty accepts only one connection and once it exists, gotty exists.

[ahmetb]

👍 much better. how about --once

[yudai]

Done (OMG, I forgot to mention this issue in the commit again...)!

[ahmetb]

@yudai Thanks for this feature. I downloaded the latest pre-release from github (has --once) and when I run

gotty --once -w ssh user@host

(ssh doesn't prompt for credentials, I have public-key authentication set up) and go to the URL in my browser process just dies:

[...]
2015/08/24 11:44:47 URL: http://172.20.10.4:8080/
2015/08/24 11:44:52 GET /
2015/08/24 11:44:52 GET /hterm.js
2015/08/24 11:44:52 GET /gotty.js
2015/08/24 11:44:52 GET /ws
2015/08/24 11:44:52 Last client accepted, closing the listener.
2015/08/24 11:44:52 New client connected: 127.0.0.1:49554
2015/08/24 11:44:52 Exiting...
$ 

edit: same happens with gotty --once -w top as well. Process dies before any console content is loaded on browser. However browser shows a black screen with a cursor on the first position.

[yudai]

It was a race condition issue. I pushed a commit that fixes the issue. Let me know if it still doesn't work properly.
Thank you for the feedback and report.

[ahmetb]

Will do. Btw by --once I didnt mean "accept only one client". It's just "exit when process finishes" I was trying to achieve. What's the reason for limiting clients?

[ahmetb]

@yudai I just tested the fix. it works, but as I said in the comment above "accept only one client" is pretty bad...

When I refresh the page, process just dies and my connection is dropped. I don't think this is a desirable behavior for anyone.

[yudai]

Thanks for testing.

The reason the current gotty accepts only one client (sometimes two ore more client can make a session due to the lazy implementation for race conditions) is that I feel like it's uncomfortable that the behavior of a client can affect the other clients. If there is only one client, it's always safe to exit gotty by interaction from the client (like exiting the command).

It's currently not easy to support refreshing. If you refresh your terminal window, that drops the websocket session between the gotty server and your browser. gotty recognizes that you've left from the session and simply exits the process by closing the pty (SIGHUP should be sent to the process). To support refreshing, or more precisely, reconnecting to the same process, gotty must support re-attaching to the existing pty from different clients. However, it's a kind of session management stuff and for now, I think it's out of the scope of gotty. I assume you can achieve your goal by using tmux.

What about using command like this:

gotty --once -w tmux -S /tmp/<host> new ssh <user>@<host>

I'm not sure if I understand your goal properly, so please let me know if this doesn't help you.

[yudai]

Closing as no activities last week. Please reopen if this issue still exists.

[Tommos0]

Ran into a similar issue, what I'm doing now is this:

./gotty -w bash -c "/bin/bash; killall gotty"

E.g. run something on when the user explicitly closes the shell (but does nothing on disconnect).