sshセッションから実行されるプログラムは接続に依存しますか？

sshセッションから実行されるプログラムは、クライアントへの接続に依存しますか？たとえば、接続が本当に遅い場合。それで、画面に物が印刷されるまで積極的に待機しますか？

また、接続に依存する場合、たとえば画面やby風でも発生しますか？これらのプログラムはホストから切断した後も実行され続けるためです。

注：これらの関連する質問のみが見つかりました。

• sshセッションの一時的な切断は、実行中のプログラムに影響しますか？
• 接続が失われた場合、sshを介したスクリーンセッションはどうなりますか？

プログラムの出力はバッファリングされるため、接続が遅い場合、バッファがいっぱいになるとプログラムは停止します。

を使用する場合screen、接続されたセッションへの表示を試みるために使用するバッファーもあります。しかし、screenセッションに接続プログラムがしますない場合は停止するscreen缶がリモート端末十分な速さを更新しません。接続が失われたときと同じように、プログラムはscreensオーバーフローするまでバッファを満たし続けます（最も古い情報を押し出します）。入ってくるのを見る（そしてスクロールして戻ることができる）のは、そのバッファに何が（まだ）あるかによる。screenプログラムをターミナル（および遅いSSH接続）から効果的に切り離します。

基礎となるTCP接続がRSTフラグ付きのパケットを受信すると、SSH接続が早期に終了する可能性があります。これは、一方がパケット（定期的なSSHキープアライブプローブである可能性があります）を送信したが、妥当な時間内にTCP確認応答を受信しなかった場合、またはルーターが接続が長すぎると判断した場合、またはISPは悪であるだけです。

Unixターミナルモデルでは、ターミナル接続が切断されると、ターミナルドライバーはシェルにHUP信号を送信します。シェルの終了により、シェルで実行されているプロセスにSIGHUPも送信されます。

以下からのUnixのプログラマーよくある質問、項目1.15：

SIGHUP慣例により、「端末回線がハングアップした」ことを意味する信号です。親プロセスとは関係なく、通常ttyドライバーによって生成されます（そしてフォアグラウンドプロセスグループに配信されます）。

ただし、セッション管理システムの一部としてSIGHUP、プロセスの終了時に送信されるのは正確に2つの場合があります。

• 終了するプロセスが端末デバイスに接続されているセッションのセッションリーダーである場合、その端末デバイスSIGHUPのフォアグラウンドプロセスグループ内のすべてのプロセスに送信されます。

• プロセスの死が原因となる場合には、プロセスグループが孤立になるために、そして孤立し、グループ内の1つまたは複数のプロセスをされて停止し、その後、 SIGHUPおよびSIGCONT孤立したグループのすべてのメンバーに送信されます。（孤立したプロセスグループとは、グループ内のどのプロセスにも、同じセッションの一部であるが、同じプロセスグループではない親が存在しないものです。）

SIGHUPのデフォルトのシグナルハンドラは、プロセスを終了することです。

Signal     Value     Action   Comment
----------------------------------------------------------------------
SIGHUP        1       Term    Hangup detected on controlling terminal
                              or death of controlling process

ただし、プロセスの終了を回避することは可能です。

• SIGHUPを無視するシグナルハンドラを挿入できます。ユーザーとしてそれを行うには、コマンドをでラップしnohupます。例えば：

  nohup make all &
  

• シェルに子プロセスを分離するように指示できます。たとえば、Bashにはdisown組み込みコマンドがあります。

  make all
  

  CtrlZ

  bg
  disown %1
  

  その後、SIGHUPは子（もはや子ではない）に伝搬されません。

• 一部のプログラム、特にデーモンは、上記のメカニズムを自動的に使用します。プログラムは、代替のSIGHUPハンドラーをインストールするsigaction(2)か（を使用）、新しいセッションに参加することを選択できます（setsid(2)）。
• あなたは実行することができますscreenまたはtmuxSSH接続ダイスSIGHUPを受信しないシェルとのセッションを実行するために擬似TTYを割り当てています。SIGHUPは、SSHセッションからscreen / tmuxセッションに中継されません。

ちなみに、信頼できないSSH接続に対処する別の方法は、代わりにMoshプロトコルを使用することです。MoshはUDP上で実行されるため、リセットされるリスクのあるTCP接続はありません。

はい、SSHを介して実行されるプログラムは、出力がどこかに行くことに依存します。接続が遅い場合、出力をどこかにバッファリングする必要があり、バッファを無限にすることはできないため、プログラムはそれらがいっぱいになるとブロックする必要があります。

出力は必ずしも端末に送られるとは限らないことに注意してください。次のような実行を検討してください。

ssh user@somewhere "cat file.txt" > file.txt

これにより、実際にファイルがコピーされます。これが機能するには、catの出力レートが接続の出力レートと一致する必要があります。出力の一部が中央から失われることは許容できないことは明らかです。

画面は、端末のように機能するという点で状況を変え、「端末ウィンドウ」に表示されるべきものを保存します（さらにスクロールバック）。プログラムが出力するすべてを記憶する必要はなく、「ウィンドウ」とスクロールバックに適合する部分のみを記憶する必要があります。デフォルトでは、画面は遅い接続を待機します（プログラムをブロックします）が、「非ブロックオン」を設定することにより、スタックした接続を検出するように構成できます。

manページから：

ノンブロック[on | off | numsecs]

出力を受け入れなくなるユーザーインターフェイス（ディスプレイ）の処理方法を画面に伝えます。これは、ユーザーが^ Sを押すか、TCP /モデム接続が切断されてもハングアップが受信されない場合に発生する可能性があります。nonblockがオフの場合（これがデフォルトです）、画面が再起動して出力を受け入れるまで待機します。非ブロックがオンの場合、画面はタイムアウトに達するまで待機します（オンは1として扱われます）。それでもディスプレイが文字を受信しない場合、画面はそれが「ブロック」されていると見なし、文字の送信を停止します。ある時点で文字を受け入れるために再起動すると、画面の表示がブロック解除され、更新されたウィンドウの内容が再表示されます。

切断は、低速接続とは異なります。プレーンSSHは自動的に復旧できないため、プログラムはSIGHUPを受け取ります。一方、画面は切断を検出し、切り離し、画面が再接続されるまでローカルバッファリングにフォールバックします。これは実行中のプログラムをブロックしません。

（nonblock 1あなたの設定は、.screenrc出力を継続的に生成するが、同時にネットワークと通信する必要があるirssiのようなものを実行する場合に重要です。