I am using the command above because, once aliased, it seems simpler to me. Then if you do a pkill -SIGUSER1 mosh-server it will only kill mosh-servers that have not been connected in the last 300 seconds (the others will ignore the SIGUSER1). You can set it to something like 300 in your. Theuser pts/17 08:31 (17X.XX.248.9 via mosh )Īn alternative is to use the mosh-server environment variable MOSH_SERVER_SIGNAL_TMOUT. Here is an example who result for reference: $ who So it finds the pids for just the detached mosh sessions and passes them to kill using xargs. That command depends on the fact that who lists connected users including mosh sessions, only attached mosh sessions have "via mosh", and that mosh sessions have their pid in square brackets. who | grep -v 'via mosh' | grep -oP '(?<=mosh \)' | xargs kill To kill only detached sessions you can use the following line (which I have as an alias in my. you restarted your laptop) your only option is to kill the sessions. I believe this is what Annihilannic and eskhool were suggesting.Īs pointed out, the mosh owners are very against reattaching from different clients for security reasons. I assume you can do the same with tmux, though I have not tried it. Now, htop (or whatever process was running) is back just as it was without interruption.This is especially useful for running upgrades or other processes that would leave the server in a messy, unknown state if suddenly interrupted. Mosh: You have a detached Mosh session on this server (mosh ).Īll I have to do is kill the prior mosh sessionĪnd reattach to the screen session, which still exists. I connect again via mosh and get that message on the server, I lose connection (laptop battery dies, lose network connection, etc.). I've then run screen and have a process running in the screen session, htop, for example. Scenario: I'm logged into a remote server via mosh. Many Mosh users use it together with screen and like it that way." Mosh is a substitute (in some cases) for SSH, not for screen. "Well, first off, if you want the ability to attach to a session from multiple clients (or after the client dies), you should use screen or tmux. I realize this is an old post, but there is a very simple solution to this, as suggested by Keith Winstein, mosh author, here: (Obviously you'd need to write something to perform the checkpoints regularly enough to be useful. autogen.sh if you've just cloned it for the first timeĪfter that, your CRIU-checkpointed mosh client sessions will survive reboots. Then, search for GETTIME and comment out that line.Īutoreconf # or. In order to fix this, you need to tell mosh to stop doing that and download the mosh source code. This will NOT work, however, if your laptop just flat out crashes it won't work because mosh sequence numbers will be out of sync with the version that was checkpointed (the binary will resume, but communication will stop). One thing to note, however, is that if your laptop reboots (which is the whole point of what we're trying to protect against), mosh uses a monotonic clock to track time on the client side, which doesn't work across reboots. criu restore -D checkpoint -shell-jobĪnd, there it is. criu dump -D checkpoint -t PID -shell-job Then, install CRIU according to their instructions. To my amazement, I used CRIU ( ) to checkpoint and restart a mosh client and it worked.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |