☰

SSH 接続を切断すると、tmux セッションが終了します。

tag-icon • tag-icon tmux sshd
SSH 接続を切断すると、tmux セッションが終了します。

一般化する：Sshが切断されたときにtmuxセッションが終了する理由を見つけようとしています。

詳細:

Arch Linuxシステムにtmuxをインストールしました。 tmux セッションを開始すると、tmux セッションを切り離して、ssh セッションがアクティブな間に再接続できます。しかし、sshセッションを終了すると、tmuxセッションは終了します。

SSHセッションが終了してもtmuxセッションが実行され続ける他のシステムがあり、新しいSSH接続を確立した後にtmuxセッションに接続できるため、これは正常な動作ではないことがわかります。問題のシステムと動作するシステムは、構成が非常に似ているため、何を確認するのかわかりません。

私はtmuxバージョン1.9aを実行しています。問題のあるシステム（ルートアクセス権がある）のLinuxカーネルバージョンは3.17.4-1で、ジョブシステムのカーネルバージョンは3.16.4-1-ARCH（システムへのルートアクセス権がありません）です。カーネルバージョンが問題の原因であると疑われますが、私が気づいた違いだけです。

似たような問題を見た人がいて、可能な解決策を知っている人がいるかどうか尋ねたいと思いました。

問題を引き起こす具体的な手順は次のとおりです。

  1. SSH経由でマシンに
  2. tmuxtmuxを起動するには実行してください。
  3. ctrl-B D取り外し（この時点で再接続できます）tmux attach
  4. SSHセッションを閉じます。 （この時点でtmuxセッションが終了しました。別の端末でrootとしてログインしたときにこれを観察できました。）
  5. sshを再接続して実行すると、メッセージが表示され、tmux attachreturnがno sessions実行されます。サービスが実行されていないため、これは意味があります。私が理解していないのは、SSHセッションが切断されたときにステップ4で終了する理由です。tmux lsfailed to connect to server: Connection refused

追跡データ：

コメントの1つに応答して、straceを使用してtmuxサーバープロセスで行われたシステムコールを確認しました。 sshセッションを終了すると（入力exitまたは使用を通じてctrl-d）、tmuxプロセスが終了するように見えます。これはstrace出力の最後の部分のスニペットです。

poll([{fd=4, events=POLLIN}, {fd=11, events=POLLIN}, {fd=6, events=POLLIN}], 3, 424) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
sendto(3, "\17", 1, 0, NULL, 0)         = 1
+++ killed by SIGKILL +++

私はこれをtmuxがうまく動作する他のシステムと比較しましたが、そのシステムではシャットダウン後もtmuxプロセスが実行され続けます。したがって、根本的な原因は、SSHセッションを閉じるとtmuxプロセスが終了するようです。理由を見つけるには、この問題を解決するのに少し時間がかかりますが、straceの提案が役に立つので、質問を更新する必要があると思いました。

答え1

理論

一部のinitシステム（systemdを含む）は、サービスに属するすべてのプロセスを終了する機能を提供します。サービスは通常、同じタスクを実行できるより多くのプロセスを作成するために分岐プロセスを開始します。これらすべてのプロセスは通常、サービスの一部と見なされます。 systemd では、次のコマンドを使用して実行されます。cgroup。

systemd では、デフォルトでサービスが停止すると、そのサービスに属するすべてのプロセスが終了します。 SSHサーバーは明らかにサービスの一部です。サーバーに接続すると、通常はSSHサーバーが分岐し、新しいプロセスがSSHセッションを処理します。 SSH セッション・プロセスまたはそのサブプロセスから分岐して、ユーザー・プロセスを含む他のサーバー側プロセスを開始できます。画面またはマルチプレクサ。

キルモードとソケットの有効化

デフォルトの動作はディレクティブを使用して変更できますKillMode。私が知る限り、アップストリームプロジェクトには.serviceファイルが含まれていないので、これらのファイルはリリースごとに異なります。通常、システムでSSHを有効にする方法は2つあります。 1つは、ssh.serviceネットワークを受信する長期実行SSHデーモンを維持するための古典的なものです。もう 1 つは、ssh.socket順番に開始され、1 つ[email protected]の SSH セッションのみを実行するソケットのアクティブ化によるものです。

解決策

セッションの終わりにプロセスが終了すると、ソケットの有効化が使用されている可能性があり、systemd が SSH セッションプロセスの終了を検出すると、systemd によってプロセスが終了します。この場合、2つの解決策があります。 1つは、ssh.service代わりにを使用してソケットアクティベーションを使用しないことですssh.socket。もう1つは設定セクションKillMode=processにあります。Service[email protected]

この設定は、SSHセッションプロセスの終了を防止したり、KillMode=processクラシックに役立ちます。ssh.service画面またはマルチプレクササーバーが停止または再起動したときに処理されます。

未来のメモ

この回答は明らかにある程度人気がありました。 OPではうまくいきましたが、次の理由で今後誰かには機能しない可能性があります。システムログイン 開発または構成。この回答に記載されている動作と異なる動作が発生した場合は、ログインセッションのドキュメントを確認してください。

答え2

Ubuntu 16.04（kdeネオン）のtmuxとscreenでも同じ問題が発生しました。 SSHセッションが切断されると、screen / tmuxが終了します。

簡単に言えば、systemdはデフォルト設定をkilluserprocess = yesに変更したため、生成されたすべてのプロセスはsshセッションを終了して終了します。

このコマンドを使用して数時間試した後、簡単に修正してscreen / tmuxを実行してください。

画面用

systemd-run --scope --user screen

Tmuxの場合

systemd-run --scope --user tmux

簡単にエイリアスを作成できます。

alias tmux= "systemd-run --scope --user tmux"

答え3

SSHソケットを有効にするためにsystemdを使用していますか？

もしそうなら、既知の問題。 systemdの支持者によると、これは実際には機能です。セッションが終了すると、systemdはセッションによって生成されたすべてのプロセスを終了します。 （これは役に立つと思われますが、GNUscreenまたはtmuxいいえもちろん、ユーザーがバックグラウンドプロセスを実行している他のほとんどの状況ではこれは望ましくありません。 )

もしそうなら、sshd.socket次から切り替えてみてください。sshd.service。

答え4

私は次のことがうまくいきましたhttps://pastebin.com/2cifCXGk（この参照でコピーした答え）。

/etc/systemd/system/ ファイルの生成[Eメール保護]コンテンツ：

[Unit]
Description=Start tmux in detached session
Documentation=man:tmux(1)

[Service]
Type=forking
User=%I
ExecStart=/usr/bin/tmux new-session -s %u -d
ExecStop=/usr/bin/tmux kill-session -t %u

[Install]
WantedBy=multi-user.target

次に、各ユーザーに対してサービスを有効にします。

sudo systemctl enable tmux@${USER}.service
sudo systemctl start tmux@${USER}.service
sudo systemctl daemon-reload

または、このファイルをsystemd / Userディレクトリ（除くUser=%I）に配置することもできます（例：）~/.config/systemd/user/tmux.service。これにより、systemdユーザーインスタンスの自動起動を有効にしない限り、ログイン時にtmuxサービスが開始されます。

関連情報