同じシェルで複数の接続が開始された場合、バックグラウンドで実行されているSSH接続は終了しません。

Question 1

フォアグラウンドプロセスと端末アクセス制御

何が起こっているのかを理解するには、共有端末について少し知っておく必要があります。両方のプログラムが同時に同じ端末で読み取ろうとするとどうなりますか？各入力バイトはプログラムの一つにランダムに入ります。（カーネルでRNGを使用して決定されたとおり、ランダムではなく実際には予測できないため、ランダムです。）2つのプログラムがパイプまたは別のファイルタイプから読み取ると（ある場所でバイトストリームを移動する）、何が起こりますか？すべてのバイトを複数回読み取ることができるバイト配列（通常のファイル、ブロックデバイス）とは異なり、他のデバイス（ソケット、文字デバイスなど）で発生します。たとえば、端末でシェルを実行するには、端末名を見つけて実行しますcat。

$ tty
/dev/pts/18
$ cat

その後、別の端末で実行しますcat /dev/pts/18。端末に入力し、時にはcatプロセスの1つに移動し、時には別のプロセスに移動する行を確認します。ターミナルがベーキングモードの場合、ラインは完全に予約されます。端末をネイティブモードに切り替えると、各バイトは独立して転送されます。

厄介です。確かに、あるプログラムが端末を取得し、他のプログラムがそうでないことを決定するメカニズムが必要です。まあ！一般的な状況では発生しますが、上記で設定したシナリオでは発生しません。この状況はcat /dev/pts/18最初から始まらないため、一般的ではありません/dev/pts/18。端末内で実行されていないプログラムから端末に接続することは一般的ではありません。一般的な状況では、端末でシェルを実行し、そのシェルでプログラムを実行します。これにより、フォアグラウンドのプログラムは端末を取得しますが、バックグラウンドのプログラムは端末を取得できないのがルールです。これは…ターミナル出入管理。仕組みは次のとおりです。

すべてのプロセスに制御端子（または通常、端末で開かれたファイル記述子がないため、そうではありません。）
プロセスが制御端末にアクセスしようとしたときにプロセスが前景にない場合、カーネルはそれをブロックします。（制限事項が適用されます。他の端末へのアクセスは制限されません。）
シェルは、誰がフォアグラウンドプロセスかを決定します。（実際にはフォアグラウンドプロセスグループです。）tcsetpgrp誰が前景にあるべきかをカーネルに伝えます。

これは一般的な場合に機能します。シェルでプログラムを実行すると、そのプログラムはフォアグラウンドプロセスになります。バックグラウンドでプログラムを実行すると（使用&）、プログラムはフォアグラウンドで実行されません。シェルがプロンプトを表示すると、シェルは自分を前景にインポートします。一時停止したジョブを再開すると、ジョブはfgフォアグラウンドになります。のbg場合はそうではありません。

バックグラウンドプロセスが端末からデータを読み取ろうとすると、カーネルはSIGTTIN信号を送信します。この信号の基本的な作業は、プロセスを一時停止することです（例：SIGSTOP）。プロセスの親は呼び出しによってこれを学ぶことができます。waitpidフラグを使用すると、WSTOPPED子プロセスが停止信号を受信すると、waitpid親プロセスの呼び出しが返され、親プロセスにシグナルが何であるかが通知されます。これは、シェルが「停止（tty入力）」を印刷する方法を知る方法です。 SIGTTIN によりジョブが中断されたことを通知します。

プロセスが一時停止しているため、再開または終了するまで何も起こりません（プロセスにシグナルハンドラが設定されている場合、プロセスは一時停止してから実行されないため、プロセスはシグナルをキャプチャしません）。 SIGCONTを送信してプロセスを再開できますが、プロセスが端末からデータを読み取る場合は効果がなく、すぐに別のSIGTTINを受け取ります。再開プロセスを使用すると、fgフォアグラウンドに移動して読み取りが成功します。

catこれで、バックグラウンドで実行すると何が起こるかがわかります。

$ cat &
$ 
[1] + Stopped (tty input)        cat
$

SSHの場合

それではSSHを使って同じことをしましょう。

$ ssh localhost sleep 999999 &
$ 
$ 
$ 
[1] + Stopped (tty input)        ssh localhost sleep 999999
$

キーを押すと、Enter時にはシェル（前景）に移動し、時にはSSHプロセスに移動します（この場合はSIGTTINによって中止されます）。なぜ？端末から読む場合は、sshすぐにSIGTTINを受信する必要があります。そうでない場合、SIGTTINを受信するのはなぜですか？

何が起こるかは、SSHプロセスが呼び出されることです。select関心のあるファイルへの入力がいつ利用可能か（または出力ファイルがより多くのデータを受信する準備ができたか）を知るためのシステムコール。入力ソースには、少なくとも端末とネットワークソケットが含まれます。とは異なり、readバックグラウンドselectプロセスは無効にされず、ssh呼び出し時にSIGTTINを受信しませんselect。目標selectは、何も破壊せずにデータが利用可能であることを確認することです。理想的にはselectシステムの状態はまったく変わりませんが、実際にはこれはまったく真実ではありません。select端末ファイル記述子で入力が利用可能であることをSSHプロセスに通知すると、プロセスが後で入力を呼び出すと、readカーネルは入力転送をコミットする必要があります。（そうでない場合、プロセスが呼び出されると、その時点readで使用可能な入力がない可能性があるため、戻り値はselect嘘になります。）したがって、カーネルが一部の入力をSSHプロセスにルーティングすることを決定した場合、システムがいつ実行されるかが決まります。電話が戻りますselect。次にSSHが呼び出されread、この時点でカーネルはバックグラウンドプロセスが端末からデータを読み取ろうとし、SIGTTINでそれを一時停止します。

同じサーバーに対して複数の接続を開始する必要はありません。一つで十分です。複数の接続によって問題が発生する可能性が高くなります。

解決策：端末から読まないでください。

端末からデータを読み取るためにSSHセッションが必要な場合は、フォアグラウンドで実行してください。

端末からデータを読み取るためにSSHセッションが必要ない場合は、入力が端末から出ていないことを確認してください。これを行う方法は2つあります。

入力をリダイレクトできます。
```
ssh … </dev/null
```
-n端末接続を転送しないようにSSHを使用または指示できます-f。（-nと同じです</dev/null。SSH-f自体が端末から読み取ることができます（パスワードを読むなど）。ただし、コマンド自体は端末を開けません。）
```
ssh -n …
```

端末とSSHの間の切断は、クライアント側で行わなければなりません。サーバーで実行されているプロセスはsleep端末からデータを読み取ることはありませんが、SSHはこれを知りません。クライアントが標準入力から入力を受け取ったら、それをサーバーに渡す必要があります。これにより、アプリケーションがそれを読み取りに決定した場合、バッファーでデータを使用できるようになります。アプリケーションがを呼び出すと、selectデータが利用できることを知らせます。）。

Answer

フォアグラウンドプロセスと端末アクセス制御

何が起こっているのかを理解するには、共有端末について少し知っておく必要があります。両方のプログラムが同時に同じ端末で読み取ろうとするとどうなりますか？各入力バイトはプログラムの一つにランダムに入ります。（カーネルでRNGを使用して決定されたとおり、ランダムではなく実際には予測できないため、ランダムです。）2つのプログラムがパイプまたは別のファイルタイプから読み取ると（ある場所でバイトストリームを移動する）、何が起こりますか？すべてのバイトを複数回読み取ることができるバイト配列（通常のファイル、ブロックデバイス）とは異なり、他のデバイス（ソケット、文字デバイスなど）で発生します。たとえば、端末でシェルを実行するには、端末名を見つけて実行しますcat。

$ tty
/dev/pts/18
$ cat

その後、別の端末で実行しますcat /dev/pts/18。端末に入力し、時にはcatプロセスの1つに移動し、時には別のプロセスに移動する行を確認します。ターミナルがベーキングモードの場合、ラインは完全に予約されます。端末をネイティブモードに切り替えると、各バイトは独立して転送されます。

厄介です。確かに、あるプログラムが端末を取得し、他のプログラムがそうでないことを決定するメカニズムが必要です。まあ！一般的な状況では発生しますが、上記で設定したシナリオでは発生しません。この状況はcat /dev/pts/18最初から始まらないため、一般的ではありません/dev/pts/18。端末内で実行されていないプログラムから端末に接続することは一般的ではありません。一般的な状況では、端末でシェルを実行し、そのシェルでプログラムを実行します。これにより、フォアグラウンドのプログラムは端末を取得しますが、バックグラウンドのプログラムは端末を取得できないのがルールです。これは…ターミナル出入管理。仕組みは次のとおりです。

すべてのプロセスに制御端子（または通常、端末で開かれたファイル記述子がないため、そうではありません。）
プロセスが制御端末にアクセスしようとしたときにプロセスが前景にない場合、カーネルはそれをブロックします。（制限事項が適用されます。他の端末へのアクセスは制限されません。）
シェルは、誰がフォアグラウンドプロセスかを決定します。（実際にはフォアグラウンドプロセスグループです。）tcsetpgrp誰が前景にあるべきかをカーネルに伝えます。

これは一般的な場合に機能します。シェルでプログラムを実行すると、そのプログラムはフォアグラウンドプロセスになります。バックグラウンドでプログラムを実行すると（使用&）、プログラムはフォアグラウンドで実行されません。シェルがプロンプトを表示すると、シェルは自分を前景にインポートします。一時停止したジョブを再開すると、ジョブはfgフォアグラウンドになります。のbg場合はそうではありません。

バックグラウンドプロセスが端末からデータを読み取ろうとすると、カーネルはSIGTTIN信号を送信します。この信号の基本的な作業は、プロセスを一時停止することです（例：SIGSTOP）。プロセスの親は呼び出しによってこれを学ぶことができます。waitpidフラグを使用すると、WSTOPPED子プロセスが停止信号を受信すると、waitpid親プロセスの呼び出しが返され、親プロセスにシグナルが何であるかが通知されます。これは、シェルが「停止（tty入力）」を印刷する方法を知る方法です。 SIGTTIN によりジョブが中断されたことを通知します。

プロセスが一時停止しているため、再開または終了するまで何も起こりません（プロセスにシグナルハンドラが設定されている場合、プロセスは一時停止してから実行されないため、プロセスはシグナルをキャプチャしません）。 SIGCONTを送信してプロセスを再開できますが、プロセスが端末からデータを読み取る場合は効果がなく、すぐに別のSIGTTINを受け取ります。再開プロセスを使用すると、fgフォアグラウンドに移動して読み取りが成功します。

catこれで、バックグラウンドで実行すると何が起こるかがわかります。

$ cat &
$ 
[1] + Stopped (tty input)        cat
$

SSHの場合

それではSSHを使って同じことをしましょう。

$ ssh localhost sleep 999999 &
$ 
$ 
$ 
[1] + Stopped (tty input)        ssh localhost sleep 999999
$

キーを押すと、Enter時にはシェル（前景）に移動し、時にはSSHプロセスに移動します（この場合はSIGTTINによって中止されます）。なぜ？端末から読む場合は、sshすぐにSIGTTINを受信する必要があります。そうでない場合、SIGTTINを受信するのはなぜですか？

何が起こるかは、SSHプロセスが呼び出されることです。select関心のあるファイルへの入力がいつ利用可能か（または出力ファイルがより多くのデータを受信する準備ができたか）を知るためのシステムコール。入力ソースには、少なくとも端末とネットワークソケットが含まれます。とは異なり、readバックグラウンドselectプロセスは無効にされず、ssh呼び出し時にSIGTTINを受信しませんselect。目標selectは、何も破壊せずにデータが利用可能であることを確認することです。理想的にはselectシステムの状態はまったく変わりませんが、実際にはこれはまったく真実ではありません。select端末ファイル記述子で入力が利用可能であることをSSHプロセスに通知すると、プロセスが後で入力を呼び出すと、readカーネルは入力転送をコミットする必要があります。（そうでない場合、プロセスが呼び出されると、その時点readで使用可能な入力がない可能性があるため、戻り値はselect嘘になります。）したがって、カーネルが一部の入力をSSHプロセスにルーティングすることを決定した場合、システムがいつ実行されるかが決まります。電話が戻りますselect。次にSSHが呼び出されread、この時点でカーネルはバックグラウンドプロセスが端末からデータを読み取ろうとし、SIGTTINでそれを一時停止します。

同じサーバーに対して複数の接続を開始する必要はありません。一つで十分です。複数の接続によって問題が発生する可能性が高くなります。

解決策：端末から読まないでください。

端末からデータを読み取るためにSSHセッションが必要な場合は、フォアグラウンドで実行してください。

端末からデータを読み取るためにSSHセッションが必要ない場合は、入力が端末から出ていないことを確認してください。これを行う方法は2つあります。

入力をリダイレクトできます。
```
ssh … </dev/null
```
-n端末接続を転送しないようにSSHを使用または指示できます-f。（-nと同じです</dev/null。SSH-f自体が端末から読み取ることができます（パスワードを読むなど）。ただし、コマンド自体は端末を開けません。）
```
ssh -n …
```

端末とSSHの間の切断は、クライアント側で行わなければなりません。サーバーで実行されているプロセスはsleep端末からデータを読み取ることはありませんが、SSHはこれを知りません。クライアントが標準入力から入力を受け取ったら、それをサーバーに渡す必要があります。これにより、アプリケーションがそれを読み取りに決定した場合、バッファーでデータを使用できるようになります。アプリケーションがを呼び出すと、selectデータが利用できることを知らせます。）。

Question 2

マンページでヘルプを見つけることができます。

 -n      Redirects stdin from /dev/null (actually, prevents reading from stdin).  This must be used when ssh is run in the
         background.  A common trick is to use this to run X11 programs on a remote machine.  For example, ssh -n
         shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically
         forwarded over an encrypted channel.  The ssh program will be put in the background.  (This does not work if ssh
         needs to ask for a password or passphrase; see also the -f option.)

-Tそれでも問題が解決しない場合は、即興（仮想tty割り当てを無効にする）を試してみましょう。

Answer

マンページでヘルプを見つけることができます。

 -n      Redirects stdin from /dev/null (actually, prevents reading from stdin).  This must be used when ssh is run in the
         background.  A common trick is to use this to run X11 programs on a remote machine.  For example, ssh -n
         shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically
         forwarded over an encrypted channel.  The ssh program will be put in the background.  (This does not work if ssh
         needs to ask for a password or passphrase; see also the -f option.)

-Tそれでも問題が解決しない場合は、即興（仮想tty割り当てを無効にする）を試してみましょう。

Question 3

明らかに、同じシェルが同じサーバーへの複数のSSH接続を開始すると、指定されたコマンドを実行した後に返されず、永久に停止します（中止（tty入力））。

これは、TTYへの同時アクセスの一般的な動作です。プロセス全体がすでにバックグラウンドで実行されており、出力を書き込もうとすると、TTYへのアクセスが許可されておらず、プロセスが捕捉できSIGTTOUない信号（）を受け取るため、基本操作（）が実行されます。bashStop

この-nオプションについては後述する。その他の回答あるいは、IOをいくつかのファイルにリダイレクトすると便利です。もっと説明する内容があるかどうかはわかりませんが、あれば説明してください。

Answer

明らかに、同じシェルが同じサーバーへの複数のSSH接続を開始すると、指定されたコマンドを実行した後に返されず、永久に停止します（中止（tty入力））。

これは、TTYへの同時アクセスの一般的な動作です。プロセス全体がすでにバックグラウンドで実行されており、出力を書き込もうとすると、TTYへのアクセスが許可されておらず、プロセスが捕捉できSIGTTOUない信号（）を受け取るため、基本操作（）が実行されます。bashStop

この-nオプションについては後述する。その他の回答あるいは、IOをいくつかのファイルにリダイレクトすると便利です。もっと説明する内容があるかどうかはわかりませんが、あれば説明してください。

同じシェルで複数の接続が開始された場合、バックグラウンドで実行されているSSH接続は終了しません。

詳細

答え1

フォアグラウンドプロセスと端末アクセス制御

SSHの場合

解決策：端末から読まないでください。

答え2

答え3

関連情報