Wipe detached sessions

[gsf]

Since mosh can't reattach to detached sessions, it should either automatically remove detached sessions or at least provide a --wipe convenience flag to wrap the grepping and killing of processes. See earlier issues around detached sessions: #394, #346, and #403.

[keithw]

I think we would say that Mosh can reattach to detached sessions; the mosh-client automatically reattaches to the corresponding mosh-server as soon as it comes back online.

The server doesn't know which clients are going to come back and which are gone for good, so I don't really want to make a --wipe that kills all servers that haven't heard from their clients in a while. We do list the PIDs of the detached mosh-servers but it's up to the user to know which are going to see a client later and which won't.

The "right thing" to do here is to make the client kill servers that are detached and waiting for new connections from the same client system, since the client can probably see whether those mosh-clients are still running. The devil is in the details here, though, re: how you identify the "same client system" in a world of containers, chroots, VMs, etc. REX did this but I don't know if it was robust to containers and other stuff.

Closing this for the same reason as #394, #346, and #403, but if you want to submit code to try to do this right, we're eager for it.

[gsf]

Glad to see your thoughts on the issue. I can definitely see the difficulty in doing the right thing when killing servers automatically. It still seems like when I log on and see the "Mosh: You have a detached Mosh session on this server (mosh [28612])." message I should be able to do something from within mosh, since the client knows there's a detached session, and I know it's due to a connection that was dropped. Maybe the --wipe convenience method should be on the client, with a description like "wipe all detached sessions on connect".

Or, now that I know I can just kill 28612 when I see that message, I can just do that. Maybe that should be explained in the message to make it clearer what one's options are at that point.

[keithw]

I totally agree that, at the minimum, we should make the message clearer. (And there are many others who agree with you...) I would happily take a patch for this.

[mgalgs]

+1 for a clearer message regarding "detached" sessions. I'm satisfied and agree with mosh not supporting resume or --wipe, but I went through the same thought process as many others:

1. "hey, I wonder if I can reattach to those sessions..."
2. google around, read about why it doesn't make sense for mosh to support that...

[cyberplant]

What do you think about having a timeout on the server?

I'm newbie to mosh and sounds very good to me. I'm used to screen, but this is different. I'm from Uruguay and here the ISP changes IP every 12 hours, so when I'm not at home I've to deal with client-IP-changes and server-IP-changes. The first ones are managed OK with mosh, but when server IP changed, mosh didn't reconnect and I had to spawn a new mosh, and found a bit annoying to have to manually kill the previous mosh.

In my case, I can set a timeout of 6 hours to mosh-server, and if no mosh-client connects in more than 6 hours, the process dies.

Thanks for mosh!

[andersk]

This is a duplicate of #12.

FYI, if you use screen inside mosh, then connecting and running screen with a single command:
mosh HOST -- screen -rd
will make sure that reattaching the screen will cause other screen clients to exit, taking their surrounding mosh-server with them.

[cyberplant]

Yes, I know about that, but I'm not always use screen, so the timeout is still a good idea for me.

And when I use screen, I almost always use screen -x cause I attach from different machines/devices and don't want to deattach the others. For example, attaching from my mobile phone to check the result of a process in a window when I'm away from my workstation.

[allo-]

screen -rd only works, if you used exec screen on the initial login shell, doesn't it? So there should be an optional timeout switch, to kill the shell in which screen, tmux or worse, any program which cannot be reattached was started.

[LwsBtlr]

A command to clean detached mosh sessions would be very helpful. perhaps with a flag for the number of days since last activity before a session is removed.

After using mosh fairly lightly from only a couple of devices (Blink on iOS and mosh from the command line of a couple of machines) I can easily stack up a dozen detached sessions and removing each one individually is a chore. I am not sure what the exact mechanism for restoring a connection is, but at least in Blink it seems to start a new session if it's been more than a day since I last connected. Might be an issue with Blink?

[keithw]

@LwsBtlr Please see the mosh-server(1) man page -- we now have a timeout that can automatically clean up old sessions (or can clean them up in response to a signal).

[NightMachinery]

See
https://git.zx2c4.com/mosh-cleaner/about/

[matonga]

I think this could be handled conveniently by the mosh-client, by taking note of the machine's mac addresses, as I really doubt someone would clone a VM without changing them. Most virtualization tools take care of this automatically. Plus it would also work for physical machines too. The only problem I can see if you hot-swap network cards (is that even possible?) on physical machines, other than that if you shutdown the machine first then you have already closed or killed all relevant mosh-client instances anyway.