Hi all,
I've seen several posts in various places about the Mosh's lack of ability
to re-connect to a session on a mosh server after the mosh client that
created it had been terminated. If you reconnect, even from the same
system and to the same user account on the server, you're greeted with the
message "Mosh: You have a detached Mosh session on this server". This is
extremely frustrating to me because it's basically just saying... "there's
a session on this server running your stuff, but ¯\_(ツ)_/¯"
Each time this issue is brought up, the solution suggested is to use
something like GNU Screen or tmux to maintain the persistence of your
session, and reconnect to that as needed. Obviously, that's a good bit of
manual effort each time you start a mosh session. My opinion on the matter
is that a purposeful integration should be developed for these tools (or
other similar ones) to automate their use with mosh, but that's a
discussion for the dev mailing list I think.
My purpose for this message was to present my own minimal set of changes to
my servers/clients to allow reconnecting to sessions automatically. These
changes were developed for my own use cases, so make of them what you will
and feel free to suggest changes if you think of any better ways to do what
I'm doing, or just ignore me. ;)
Here's the TLDR of what my changes do:
- On the client end:
1. Create a wrapper shell script around the "mosh" client executable.
2. Add an alias entry into .bashrc or .bash_profile to intercept the
use of the "mosh" executable
3. The wrapper script creates a token string which should be unique
to the client system which is passed as an environment variable
to the mosh
server upon launching a new session.
- On the server end, add a small block of shell script into .bashrc or
.bash_profile which starts/resumes a screen session automatically, but only
if the shell was started from mosh_server and if the CLIENT_UUID variable
is defined and non-empty.
- The CLIENT_UUID which is passed from client to server provides a way
to tie a session to a client system it was initiated from, meaning that it
won't be automatically resumed if I mosh from another client system (but
could be manually, if so desired).
- Client-side requirements: bash, md5sum (coreutils), awk
- Server-side requirements: bash, ps (tested on Linux, can't guarantee
Unix/Mac support to the ps options I used)
And here's the nitty-gritty changes:
- Create a wrapper script somewhere (I put mine in a ~/bin directory
which I've included on my $PATH). It should contain the following script
code:
#!/bin/bash
# Find the block device associated with the root partition
ROOT_BLK_DEV=$(readlink -f $(df --output=source -h / | tail -1))
ROOT_UUID=""
# Find the UUID of the root partition's block device
for uuid in $(ls /dev/disk/by-uuid/); do
BLK_DEV=$(readlink -f /dev/disk/by-uuid/"$uuid")
if [ "$ROOT_BLK_DEV" == "$BLK_DEV" ]; then
export ROOT_UUID="$uuid"
break
fi
done
# If we can't find the root UUID, hash the user@hostname and use that
instead
if [ "$ROOT_UUID" == "" ]; then
hostname="$(hostname -f)"
export ROOT_UUID=$(echo "${USER}@${hostname}" | md5sum | awk '{ print $1
}')
fi
# Call the standard mosh client, sending the UUID to the server, and
passing the user's args
CLIENT_EXEC=$(which mosh)
$CLIENT_EXEC --server="CLIENT_UUID=\"$ROOT_UUID\" mosh-server" "$@"
- Add the following entry into .bashrc or .bash_profile on the
*client* (obviously,
this should be modified to point to the location of the wrapper script you
created):
alias mosh="/home/user/bin/mosh_client.sh"
- Add the following entry into the .bashrc or .bash_profile on the
*server*:
PARENT_EXEC=$(ps --no-headers -o command -p $PPID | awk '{ print $1 }')
if [ "$PARENT_EXEC" == "mosh-server" ]; then
if [ "$CLIENT_UUID" != "" ]; then
screen -DR "$CLIENT_UUID"
exit
fi
fi
I was thinking about creating a way to automatically deploy this on servers
as I connected to them, but I'm hesitant to do such things, as automated
tampering of the .bashrc/.bash_profile files could introduce subtle "I
can't login to my server" bugs.
Anyway, this effort was quick-and-dirty, and I know it's probably got some
warts, so I'm open to critique if you all are interested.
Thanks,
Jared
_______________________________________________
mosh-users mailing list
mosh-users@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-users
