SSHセッションから切断されるとプログラムが停止しますか？

そのため、開始した後rsync、cpまたは長時間実行される可能性のある他のコマンドの後に、SSHセッションから切断されたとします。そのコマンドは、切断されてから終了するまで実行されますか、それとも単に殺されますか？

常にこれを疑問に思いました。

2016年の編集：

このQ＆Aは、systemd v230の大失敗に先立ちます。systemd v230の時点で、これを防ぐために歴史的に有効な予防策が講じられていたかどうかに関係なく、新しいデフォルトは、終了するログインセッションのすべての子を殺します。動作は設定により変更可能KillUserProcesses=noで/etc/systemd/logind.conf、またはユーザスペースでデーモンを開始するためにsystemd固有のメカニズムを使用して回避します。これらのメカニズムはこの質問の範囲外です。

以下のテキストは、Linuxが存在するよりも長い間UNIXデザインスペースで物事が伝統的にどのように機能してきたかを説明しています。

彼らは殺されますが、必ずしも即座に殺されるわけではありません。SSHデーモンが接続が停止したと判断するのにかかる時間に依存します。以下は、実際の動作を理解するのに役立つ長い説明です。

ログインすると、SSHデーモンが擬似端末を割り当てて、ユーザーの構成済みログインシェルに接続します。これは、制御端末と呼ばれます。その時点で通常起動するすべてのプログラムは、シェルの深さが何層であっても、最終的にはその祖先をそのシェルまでさかのぼります。これはpstreeコマンドで確認できます。

接続に関連付けられているSSHデーモンプロセスは、接続が停止していると判断すると、ハングアップ信号（SIGHUP）をログインシェルに送信します。これにより、シェルが消失したこと、およびシェル自体のクリーンアップを開始する必要があることが通知されます。この時点で行われるのはシェル固有です（ドキュメントページで「HUP」を検索してください）が、ほとんどのSIGHUP場合、終了する前に関連する実行中のジョブへの送信を開始します。これらの各プロセスは、そのシグナルを受信したときに実行するように構成されていることを順番に実行します。通常、それは終了を意味します。それらのジョブに独自のジョブがある場合、信号も同様に頻繁に渡されます。

制御端末のハングアップを切り抜けるプロセスは、端末（その内部で開始したデーモンプロセス）からの関連付けを解除するプロセス、またはプレフィックス付きnohupコマンドで呼び出されたプロセスです。（つまり、「これにハングアップしないでください」）デーモンはHUPシグナルを異なる方法で解釈します。制御端末がなく、HUP信号を自動的に受信しないため、代わりに管理者からの手動要求として構成を再ロードするために再利用されます。皮肉なことに、これは、ほとんどの管理者が、非常に遅くまで、非デーモンに対するこのシグナルの「ハングアップ」使用法を学習しないことを意味します。それがあなたがこれを読んでいる理由です！

ターミナルマルチプレクサは、接続が切断されるまでシェル環境を損なわないようにする一般的な方法です。それらは、その切断が偶発的であるか意図的であるかに関係なく、後で再接続できる方法でシェルプロセスから分離することができます。tmuxそしてscreen、より人気のあるものです。それらを使用するための構文は質問の範囲を超えていますが、検討する価値があります。

SSHデーモンが接続が切断されていると判断するまでにかかる時間について詳しく説明するように依頼されました。これは、SSHデーモンのすべての実装に固有の動作ですが、いずれかの側がTCP接続をリセットすると、それらすべてが終了することを期待できます。これは、サーバーがソケットへの書き込みを試行してTCPパケットが確認されない場合はすぐに発生し、PTYへの書き込みが何も試行されていない場合はゆっくり発生します。

この特定のコンテキストでは、書き込みをトリガーする可能性が最も高い要因は次のとおりです。

• サーバー側でPTYに書き込もうとするプロセス（通常はフォアグラウンドにあるプロセス）。（サーバー->クライアント）
• クライアント側でPTYに書き込もうとするユーザー。（クライアント->サーバー）
• あらゆる種類のキープアライブ。これらは通常、クライアントまたはサーバーによってデフォルトで有効にされておらず、通常、アプリケーションレベルとTCPベース（つまりSO_KEEPALIVE）の2つのフレーバーがあります。キープアライブは、他の方法でソケットに書き込む理由がない場合でも、サーバーまたはクライアントのどちらかが相手にパケットを送信することはまれです。これは通常、接続のタイムアウトが速すぎるファイアウォールを回避することを目的としていますが、反対側がそれほど速く応答していないときに送信者に気付かせるという副作用があります。

TCPセッションの通常のルールがここに適用されます：クライアントとサーバー間の接続が中断されたが、どちらの側も問題の間にパケットを送信しようとしない場合、両方の側が応答し、予想されるTCPを受信する場合、接続は存続しますシーケンス番号。

片方がソケットが死んでいると判断した場合、効果は通常すぐに発生します。sshdプロセスは送信HUPして自己終了します（前述のとおり）、またはクライアントが検出された問題をユーザーに通知します。片方がもう片方が死んでいると思っているからといって、もう片方がこのことを通知されているわけではないことに注意してください。接続の孤立した側は、通常、書き込みを試みてタイムアウトになるか、相手側からTCPリセットを受信するまで開いたままになります。（その時点で接続が使用可能であった場合）この回答で説明されているクリーンアップは、サーバーが気づいたときにのみ行われます。

他の人が述べたように、sshから切断すると、その中で実行されているものはすべて消えます。

以下のよう@Michaelハンプトンと他の人が言及しているあなたは、のようなツールを使用することができるtmuxか、screenその内容（つまり、子プロセス）を失うことなく、端末に再接続/切断します。

さらに、アンパサンド&を使用してプロセスをバックグラウンドに配置し、コマンドdisownを使用してそれらを現在のシェルとの関連付けを解除できます。

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

いいえ、まだ端末に接続されていて、などのようnohupにバックグラウンドに配置されていないプログラムはすべて強制終了されます。

これが、切断されても実行を継続し、後で再接続できるセッションを作成するtmux、以前のような仮想端末ソリューションがある理由screenです。