tmuxビルドサーバーで使用します。最近、セッションが終了した場合にセッションへのアタッチを自動化する小さな.bashrcスクリプトを作成しtmuxました。スクリプトは次のようになります
# Automate tmux Startup
if [ -z "$TMUX" ]; then
# we're not in a tmux session
if [ `ps -o comm= -p $PPID` == "sshd" ]; then
# even VNC can have $SSH_TTY and $SSH_CONNECTION set so we cant find out
# if we want to attach to tmux during ssh so we need to see if parent
# process is sshd see
# http://unix.stackexchange.com/questions/145780/linux-ssh-connection-is-set-even- without-sshing-to-the-server
# Only attach to tmux if its me
WHOAMI=$(whoami)
if tmux has-session -t $WHOAMI 2>/dev/null; then
tmux -2 attach-session -t $WHOAMI
else
echo "Start tmux with username as session name 'tmux new -s $WHOAMI' "
fi
fi #parent process check
else
echo "Inside tmux"
fi
問題は、それをssh使用moshすると tmux ウィンドウ内でハングアップすることです。このスクリプトを削除してから mosh を使用して ssh を使用し、手動で tmux にアタッチすると、この問題は発生しないことがわかりました。この問題は、上記のスクリプトを に配置した場合にのみ発生し.bashrcます。
私の疑いは、 mosh が.bashrc完了するのを待っていて、それを無期限に待っており、その間にマウスとキーストロークのコントロールをtmux. tmux別の端末からセッションを強制終了してこれを確認したところmosh、以前にバッファリングされたキーストロークを回復して実行しようとしたことがわかりました。
奇妙なことはmosh、チェックをどのように通過したかということですps -o comm= -p $PPID == "sshd"。これはmosh、シェルのbashプロセス名が であり、シェルの親プロセス名が ではmosh-serverないためsshdです。さらに調査した結果、が once asと once asを2 回mosh実行することが明らかになりました。これは .My を入れることで再現可能です。.bashrcsshdmosh-serverps -o comm= -p $PID -p $$ >> moshbash.bashrctmux attachsshdmosh
私が見つけた簡単な回避策は、
mosh user@server -- tmux attach -t `whoami`
ssh に対しても同様のことを実行して、クライアント側からコマンドを起動し、.bashrc スクリプトを完全に排除できますが、サーバー側の自動化をクライアント側に流出させたくありません。
実はmosh間違っていないようです。.bashrcPID ごとに 1 回だけファイルを取得しています。バックグラウンド プロセスとして開始できない端末も必要なので、ブロッキング セッションを開始するのは悪い設計だと思い.bashrcます。この問題を回避する他の方法はありますか? sshd をセットアップする mosh クライアントと sshd をセットアップする ssh クライアントを区別できれば、その情報を使用できると思います。tmuxtmux&