☰

他のコンピュータのsshコマンド

tag-icon • tag-icon ssh remote
他のコンピュータのsshコマンド

だから私はスクリプト（ただしスクリプトです）からsshを介してシステムAからシステムBにコマンドを「指示」し、それをバックグラウンドで送信します。コマンドは次のとおりです。 ssh -T MACHINEB SCRIPT &

マシン A で実行するスクリプトはタイムアウトしません。時々、私はコマンド/スクリプトの指示がマシンBに存在することに気づきましたが（私が要求した場合）、ある種のハングがありました。 psは正しいPIDとPPIDを表示しますが、それはすべてで完了しません。

プロセスが中断される原因が何であるかを見つけようとしています。私の言葉は、これがコードに関連していることをほとんど確信しているということです。次の可能性とあなたが追加できる他のすべてを削除したいと思います。

リモートSSHスクリプトの実行を実行すると、私のプロセスはSSHセッションに接続しますか？もしそうなら、AからBに移動するネットワークまたはSSHの問題がある場合、私のプロセスは影響を受けますか？

ありがとう

答え1

ssh -T MACHINEB SCRIPT &SCRIPTの実行中にSSH接続を実行し続けます。これを行う必要がある理由は次のとおりです。

  1. SCRIPTが出力を生成すると、SSHはそれをホストに渡す必要があります。
  2. SCRIPTが入力を読み取ると、SSHはそれをホストから中継する必要があります。これは少し微妙かもしれません。。
  3. SCRIPT が終了すると、SSH は終了状態をクライアントに送信し、プロセスはそのssh状態で終了します。

接続が中断された場合、SCRIPTはstdin、stdout、またはstderrを読み書きしようとしない限り影響を受けません。関連端末がないため、接続が中断されたときにSCRIPTはSIGHUPによって終了しません。ただし、SCRIPTがエラーメッセージを印刷しようとすると、メッセージは接続を介して転送されます。

2つのうちの1つを実行する必要があります。

  • バッチジョブのアプローチ：SCRIPTが入力を許可せず、標準出力と標準エラーをファイルに書き込むことを確認してください。

    ssh -T MACHINEB 'myprogram </dev/null >myprogram.log 2>&1'

  • 対話型方法：スクリーンマルチプレクサ内でSCRIPTを実行します。画面またはマルチプレクサ。

    ssh -T MACHINEB screen -S somename -dm myprogram

    このスクリーンセッションに接続すると、プログラムが動作している様子を見ることができます。

    ssh MACHINEB screen -S somename -dr

    プログラムが終了すると、スクリーンセッションも終了します。プログラムの出力とエラーを表示するには、これを維持するには、次を参照してください。実行されたスクリプトが終了したときにGNU画面がセッションを終了するのを防ぐ

また、見ることができますSSH接続から完全に切断されたリモートコマンドの実行

答え2

あなたの質問はあまり明確ではなく、やや混乱しています。しかし、問題を解決するためにいくつかの答えを提供しようとします。まず、プロセスsshはMACHINEAで実行され、SCRIPTはMACHINEBで実行されます。したがって、「＆」記号は、sshMACHINEBで実行されるSCRIPT（シェル）プロセスではなく、MACHINEAのコマンドプロセスをバックグラウンドにします。したがって、MACHINEAの（デフォルト）スクリプトは引き続き（デフォルト）スクリプトの次のコマンドを実行しますが、MACHINEBは "ssh"セッションで実行されます（MACHINEBの場合はフォアグラウンド）。したがって、AからBへの接続に問題がある場合、プロセスはバックグラウンドで実行されているsshため（おそらく中断されている可能性がある）、コマンドはMACHINEAのデフォルトスクリプトを停止しません。ssh

答え3

スクリプトを実行すると、コマンドを実行するサブシェルが生成されます。実行中のバックグラウンドプロセス（sshコマンドなど）を含むすべてのプロセスは、このサブシェルに関連付けられます。サブシェルが終了すると、バックグラウンドプロセスも終了します。代わりに、スクリプト1でnohupコマンドでsshプロセスを実行してみてください。以下からインスピレーションを受けた回答：スクリプトでバックグラウンドプロセスを開始し、スクリプトが終了したら管理します。

SSHを介して送信されたコマンドはSSHプロセスに接続され、コマンドを完了するにはSSHプロセスを実行し続ける必要があります。 SSHプロセスを終了すると、システムBのすべてのバックグラウンドプロセスがスクリプト2用に作成されたサブシェルにリンクされ、終了します。 Nohupはここでも便利です。

しかし、プロセスはマシンBで実行されていますが、明らかに停止して早期に終了していないため、sshプロセスの早期終了は問題にならないようです。

SSHプロセスを終了し、マシンBで実行されているプロセスを終了できるため、ネットワークの問題も発生する可能性が低くなります。さらに、ネットワークの問題がsshプロセスを終了するのに深刻でない場合は、システムBで実行されているプロセスに影響を与えないでください。マシンBのスクリプト2にある何かが遅延を引き起こす可能性があります。このロジックを実証する1つの方法は、システムAでsshプロセスを終了し、システムBで何が起こるかを確認することです。

結局のところ、最善の選択肢は、前のリンクで提案されているように、sshコマンドをnohupプロセスとして実行することです。また、スクリプト2のコマンドが順序に依存しない場合は、nohupを使用して各コマンドを実行します。 （https://askubuntu.com/questions/349262/run-a-nohup-command-over-ssh-then-disconnect）。 sshコマンドをバックグラウンドプロセスとして実行しているため、コンピュータAのスクリプト1にはスクリプト2の実行に依存するものがないとします。

関連情報