[mosh-users] Automated Persistent Sessions with GNU Screen

Jared Sutton jpsutton at gmail.com
Thu Jan 4 19:26:59 EST 2018


Is the project leadership open to accepting pull requests that would
integrate similar functionality into the core product?  Perhaps I should
join the Dev list and discuss there...

On Jan 4, 2018 7:11 PM, "Keith Winstein" <keithw at cs.stanford.edu> wrote:

Thanks for sending this! Very interesting, and makes me wonder whether we
should think about long-running migratable sessions in a future version of
Mosh.

Best regards,
Keith

On Thu, Dec 28, 2017 at 8:45 PM, Jared Sutton <jpsutton at gmail.com> wrote:

> 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 at 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 at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-users/attachments/20180104/4ce25a0b/attachment-0001.html


More information about the mosh-users mailing list