解決策 1:
新しい端末の現在の STD* ファイル記述子を古い実行中のプロセスに接続しようとすると、問題が発生するだけです。それができたとしても、端末のジョブ制御は期待どおりに機能しません。乗っ取られたプログラムを最終的に終了すると、混乱が残り、新しくバックグラウンド化されたプロセスに渡されるファイル記述子を犠牲にしたシェルはどうなりますか。そのシェルがなくなってもsshは開いたままになりますか?おそらくそうではありません。そのため、最初に別の場所にリダイレクトする必要があります。
可能であろうとなかろうと、放棄されたプロセスを「自然に」強制終了させる方が望ましいと思います。制御を再開するために必要なすべてのハッカーを実行しようとすることを正当化するのに十分なほど重要なことを行っている場合 および 不安定なリンクを使用している場合は、おそらく事前にそれを知っておいて、screen (または vnc、または切り離されたコントロール ボートに浮かぶもの) を使用する必要があります。 :)
解決策 2:
これが古い質問であることは承知していますが、他の誰かが私のようにこれに出くわした場合に備えて、私の調査結果を追加することが重要だと感じました.
はい、これを行うことで異常な結果は見られませんでしたが、これは私が使用したものであり、驚くほど機能しました。サーバーで長いプロセスを実行すると、ssh セッションが切断されることがあります。プロセスと tty セッションは実行されているように見えますが、再接続できません。新しく接続されたセッションにプロセスをプルする以下のプログラムを見つけました。
https://github.com/nelhage/reptyr
詳細はこちら
https://blog.nelhage.com/2011/02/ching-ctty/
解決策 3:
一般に、これを処理する正しい方法は、GNU screen を使用して事前に準備することです。 または bash の nohup または disown メカニズム。 tcsh を使用している場合 、シェルは異常終了時にバックグラウンド ジョブを否認します。
screen を使用していない場合 しかし、disown のいずれかを介してプロセスを実行し続けることができました gdb でプロセスへの再接続を偽装できる可能性があります (ソース):
[...] いくつかの汚いハックでは、プロセスの stdout/stderr/stdin を再度開くことは不可能ではありません。 [...]
次に、たとえば gdb を使用してプロセスにアタッチし、somecall close(0) を実行します。
close(1) を呼び出す
close(2) を呼び出す
open("/dev/pts/xx", ...) を呼び出す
dup(0) を呼び出す
dup(0) を呼び出す
切り離す
ここで、状況に合わせてこのプロセスを微調整する必要があります。 勘当できなかったとしたら、助けになるとは思えません プロセス。 bash を使用している場合 bash の作成に関するこの投稿を参照してください。 自動的に見捨てる 終了時のバックグラウンド プロセス (基本的に、huponexit をオフにします) ショップで ）。フォアグラウンド プロセスでは、nohup を使用している必要があります .