Hi!
I accidentally closed my local mosh window. When I'm making a new connection, mosh displays a friendly "You have a detached Mosh session on this server" message, but doesn't give any hint on _how_ to reconnect.
Even the man-page doesn't help :-/
I thought, reconnecting and handling flaky connections was one of the main features of mosh?
Please add a short help text of how to reconnect. I think it would be best to display a copy/paste'able command right in the "detached session" notification bar.
If you kill the local mosh-client, it will try to tell the server to quit.
If you do this while you're not connected, it won't be able to tell the server to quit, and it will print a warning telling you this. The session will stick around on the server forever.
Mosh does handle flaky network connections, but only by letting the _same_ mosh-client connect to its mosh-server (e.g. when network service is restored or the client comes out of sleep).
For security reasons, there is no way to attach to a mosh-server from a _new_ client. If you're sure that the corresponding client won't be coming back, the only recourse is to "kill" the mosh-server (whose PID is given in the warning).
Thanks for the suggestion to clarify the help text -- this is helpful and we will look at making this more verbose.
Ah, ok.. Is such a feature planned for a future release?
What are the security concerns behind session reattachment?
After all, I'm already authenticated by SSH to be the same trusted user. If I had used screen and plain ssh instead of mosh I'd be able to reattach my session just fine.
My notebook has a totally dead battery, and every time I trip over my power cord, I will loose my mosh connections. I was hoping mosh would obsolete screen for me.
Our standard line is that ssh and mosh provide connections, and screen and tmux provide persistent server-side sessions.
Tons and tons of people use mosh with screen or tmux. If you want to be able to attach to the same session from multiple clients, or after rebooting the client, screen/tmux is the way to go. We don't think we need to duplicate this functionality.
You can run mosh servername -- screen -dr to detach another screen session and attach to it via mosh.
I think, it would be a nice addition though.. mosh.mit.edu says that mosh "supports intermittent connectivity", and loosing a connection because of a power outage belongs to the same class of problems from a user perspective.
Not supporting one of the most common reasons for lost user connections seems like a big ommission :-/
Sorry to disappoint! We support intermittent _network_ connectivity between the sender and receiver. We don't (yet?) support intermittent connectivity to electrical power. :-)
Of course we'd welcome your contribution on this front if you want to submit some code to allow a logged-in server-side user to extract the keying material from a running server (with the same UID) and provide them to a new client.
mosh supports intermittent connectivity to electrical power just fine if the operating system can suspend to disk and there is enough battery power to do it.
I've ended up with about 12 mosh sessions running and only 3 machines. I know this issue is closed but if you end up in this situation I just ran:
kill `pidof mosh-server`
This will close all mosh connections including your existing one but it seemed like a reasonable interim solution.
The current notice [1] still doesn't give any info on what to do so I'd like to see this issue re-opened.
@keithw can the info in this thread be summarized and added to the notice?
[1] Mosh: You have a detached Mosh session on this server (mosh [PID]).
I'd love if you submitted a pull request with a suggestion for updated language -- happy to take it.
reply brief, written from phone. im assuming mosh clears the env var with the key in it? otherwise, the same authenticated local user could recover the key from the process via /proc or some such...
@jettero The key cannot be reused, even for the same session. I've tried. :) If I'm wrong, I'd love to know it.
+1 for a message about how to clear the detached session. As an example of precedent, when vim dies and leaves .swp files, it tells you how to clean up. The above commit language from @dideler seems good to me.
As there doesn't seem to be a good way to handle automatic cleanup of stale sessions ... heres a horrible hack
for server in $(ps aux | awk '/mosh-server/ { print $2 }'); do for bash in $(ps --ppid $server | awk '/bash/ { print $1 }'); do test $(ps --ppid $bash | wc -l) = 1 && kill $server; done; done
This kills mosh servers which have a bash process, and the bash process has no children. Horrible I know but it does the job for me :)
Stopping by to say I too was confused about what to do with stale connections. After reading this thread I decided I could sacrifice my current connection and ran:
killall mosh-server
That seemed to clean everything up like I wanted. (I run tmux inside of mosh so I wasn't worried about losing any state.)
We can kill all of the mosh-servers except for the last one started. My assumption is the last mosh session started is the one you are currently using.
kill $(ps --no-headers --sort=start_time -C mosh-server -o pid | head -n -1)
Yesterday I had about 20 detached sessions, today I'm locked out my headless Raspberry Pi. Could it be if too many detached sessions build up, you are no longer be able to login by mosh or ssh?
Could not connect via ssh: Socket error: No more processes
SSH Login failed.
Mosh has exited.
Can anyone suggest a solution other than pulling power to reboot?
@hickford 20 sessions isn't nearly enough to cause this problem, even considering that each will take a couple of PIDs at least.
The problem you describe is caused by something chewing up the thousands of available PIDs on the machine. One possibility is a fork bomb. Another is a service that is configured to have too many processes (check Apache, NFS, etc.).
Search the web for "no more processes" for aid here. You may be able to get back in without a hard restart, but it will depend on the root cause and likely will be tricky or impossible.
@hickford: I can't reproduce this, on an RPi2 with Raspbian and 25 sessions.
Your problem might be some other kind of resource exhaustion, for example memory, or ptys.
Mosh has some features to enable slightly easier management of detached sessions, see the text on MOSH_SERVER_NETWORK_TMOUT and MOSH_SERVER_SIGNAL_TMOUT in the mosh-server man page.
I came up with the following to close all detached sessions only. It seems cleaner than the alternatives because I don't want to kill my current session, may have more than one detached session, and may have multiple attached sessions. I posted more info on it and also on using MOSH_SERVER_SIGNAL_TMOUT at https://stackoverflow.com/a/48082431/255961.
who | grep -v 'via mosh' | grep -oP '(?<=mosh \[)(\d+)(?=\])' | xargs kill
@studgeek Wow, it's amazing how close yours is to one I just came up with:
who|awk '{print $7};'|grep -o '[0-9]\+'|xargs kill
Not sure whose is better ;-)
@studgeek @ctrlcctrlv Warning: never run any of these who | awk | grep | xargs kill pipelines on multiuser systems. The output of who is entirely controlled by those users (which is why mosh-server can write its pid there in the first place). Nothing stops them from spoofing arbitrary pids for you to kill.
@andersk good point. also i think everyone is overthinking this ...
pgrep -u "$USER" mosh-server | tr ' ' '\n' | grep -v "$PPID" | xargs kill
Just alias this and run it right when you login (with mosh) and see the message.
@keur That line is killing active sessions too... :-/
@andersk good point. also i think everyone is overthinking this ...
pgrep -u "$USER" mosh-server | tr ' ' '\n' | grep -v "$PPID" | xargs killJust alias this and run it right when you login (with mosh) and see the message.
Just don't run this from within tmux :)
Most helpful comment
We can kill all of the mosh-servers except for the last one started. My assumption is the last mosh session started is the one you are currently using.
kill $(ps --no-headers --sort=start_time -C mosh-server -o pid | head -n -1)