ドロップされたSSHセッションで実行されているコマンドを再開する

この質問を読んで不思議に思いました。仮定screenは使用されていません。何らかの理由でLinuxターゲット上のSSHセッションがドロップされ、タイムアウトのためにサーバーがセッションを強制終了する前に再接続した場合、実行中のコマンドの制御を取り戻し、セッションが中断されて中止されないようにすることは可能ですか？ ？

新しい端末の現在のSTD *ファイル記述子を古い実行中のプロセスに接続しようとすると、トラブルが発生します。たとえそれをやっても、端末のジョブ制御は期待どおりに機能しません。最終的に引き継がれたプログラムを終了すると混乱が残り、ファイル記述子を犠牲にして新たにバックグラウンド化されたプロセスに渡されるシェルはどうなりますか。そのシェルがなくなると、sshは開いたままになりますか？おそらくない。したがって、最初に別の場所にリダイレクトする必要があります。

可能かどうかに関係なく、放棄されたプロセスを「自然に」強制終了させる方が望ましいと思います。あなたが何か重要な十分にやっている場合は、すべてのハックをしようと正当化制御を再開するために必要なためにとあなたが不安定なリンクにしている、あなたはおそらく、事前だけ利用画面（またはVNCでいることを知っているべきか、何があなたdetached-を浮かびますコントロールボート）。:)

私はこれが古い質問であることを知っていますが、他の誰かが私と同じようにこれに出くわした場合に備えて、私の調査結果を追加することが重要だと感じました。

はい、これを行うことに異常な結果は見ていませんが、これは私が使用したものであり、驚くほど機能しました。サーバー上で長いプロセスを実行すると、sshセッションが切断されることがあります。プロセスとttyセッションは実行されたままになりますが、再接続できません。プロセスを新しく接続されたセッションにプルする以下のプログラムを見つけました。

https://github.com/nelhage/reptyr

詳細はこちら

https://blog.nelhage.com/2011/02/changing-ctty/

一般的に、これを処理する正しい方法は、GNU screenまたはbash nohupまたはdisownメカニズムを使用して事前に準備することです。を使用しているtcsh場合、シェルは異常終了するとバックグラウンドジョブを無視します。

使用してscreenいないが、disownメソッドの1つを使用してプロセスを実行し続けている場合、gdb（source）を使用してプロセスへの再接続を偽装できる可能性があります。

[...]いくつかの汚いハッキングでは、プロセスのstdout / stderr / stdinを再び開くことは不可能ではありません。[...]

次に、gdbを使用してプロセスにアタッチし、close（0）
call close（1）
call close（2）
call open（ "/ dev / pts / xx"、...）
call dup（0）を呼び出します。
call dup（0）
detach

ここで、状況に応じてこのプロセスを調整する必要があります。プロセスを否認することができなかったら助けになるとは思いません。あなたが使用している場合はbash、この記事を参照することについてはbash自動的に勘当（基本的には、オフ終了時にバックグラウンド・プロセスをhuponexitとshoptを）。フォアグラウンドプロセスでは、nohupを使用する必要があります。

おそらくない。私はそれが不可能であることを保証することはできませんが、私は本当にそれを疑います。

一つのことは、ssh接続の終了の結果として実行されているシェルとコマンドの強制終了の欠如です。これはそれほど難しくありません。他の質問で述べたようなnohupや同様のメカニズムを使用できるはずです。

しかし、その後、開始ssh somehost nuhup vim /some/fileして接続が切断されたと仮定します。ssh somehost再度ログインして実行すると、vimプロセスがまだ実行されていることがわかります。しかし、そのプロセスに再び接続する方法を教えてください。インタラクティブなフォアグラウンドプロセスには制御ttyがあり、vimプロセスの開始時に開かれたttyはそれ以降閉じられていました。新しいシェルで再び「再開」する方法があるかどうかはわかりません（1つのシェルで複数のバックグラウンドジョブが実行されているように、別のシェルでそれらをフォアグラウンドにすることはできません）。

Screenこの機能を持つように明示的に記述されています。起動時に、端末管理プロセスとクライアントプロセスの2つのプロセスをフォークします。相互作用はクライアント<->ターミナルマネージャー<->アプリケーションであり、接続を切断または切断すると、ターミナルマネージャーが存続している間にクライアントプロセスが終了します。画面には、後で端末管理プロセスにアタッチする特定のサポートがありますが、これは一般的なケースでは不可能だと思います。

rettyはあなたを助けることができるかもしれませんが、免責事項は非常に現実的で関連性があります:)

セッションがドロップされた場合、TTLがすでに期限切れになっていることを意味するため、これ以上のttyはありません（理解できます）。ただし、ネットワーク接続が中断された場合、SSHセッションを停止する必要はないため、接続を再開して続行できるはずです。それはあなたが尋ねていることですか？

この質問には、コードを盗むハックしたttyへのリンクがありました。理論的には、これを使用してnohupプロセスの制御を取り戻すことができるはずです。