2

更新された投稿:

ポートで実行されている Python Web アプリケーションがあります。他のいくつかのプロセスを監視するために使用され、その機能の 1 つは、ユーザーが自分のプロセスを再起動できるようにすることです。再起動は、bash スクリプトを呼び出すことによって行われます。これにより、これらのプロセスが再起動され、バックグラウンドで実行されます。

問題は、Python Web アプリケーションを使用してユーザーのプロセスを再起動した後にそのアプリケーションを強制終了すると、それらのプロセスが Python Web アプリケーションで使用されるポートをラウンドロビン方式で引き継ぐため、再起動できないことです。ポートが制限されているため、Python Web アプリケーション。その結果、Python Web アプリケーションが使用するポートが何も占有されなくなるまで、再起動に関係するプロセスを強制終了する必要があります。

ポートを占有しているプロセスを除いて、すべて問題ありません。それは本当に望ましくありません。

再起動できるプロセス:

  1. redis サーバー
  2. newrelic-admin run-program (別の Web アプリケーションを生成します)
  3. Python ワーカー プロセス

更新(2013 年 6 月 6 日): この問題を解決することができました。以下の私の答えを見てください。

元の投稿:

ポートで実行されている Python Web アプリケーションがあります。この python プログラムには、bash スクリプトを呼び出す関数があります。bash スクリプトは、いくつかのバックグラウンド プロセスを生成してから終了します。

問題は、python プログラムを強制終了するたびに、bash スクリプトによって生成されたバックグラウンド プロセスが引き継ぎ、同じポートを占有することです。

具体的には、サブプロセスは次のとおりです。

  1. redis サーバー (構成ファイルで daemonize = true を使用)
  2. newrelic-admin run-program (ウェブアプリケーションを生成)
  3. Python ワーカー プロセス

更新 2: nohup でこれらを実行してみました。Python Web アプリケーションを強制終了した後、Python ワーカー プロセスだけがポートを引き継ごうとしません。redis サーバーと newrelic-admin は引き続き使用できます。

この問題は、Python プログラムで subprocess.call を使用して bash スクリプトを実行したときに発生しました。bash スクリプトを実行する前に、python プログラムでダブル フォーク メソッドを試しましたが、同じ問題が発生します。

bash スクリプトから生成されたプロセスがポートを引き継ぐのを防ぐにはどうすればよいですか?

ありがとうございました。

更新:私の意図は、python アプリケーションが強制終了された場合でも、bash スクリプトによって生成されたプロセスが引き続き実行されることです。現在、Python アプリケーションを強制終了した後も引き続き実行されます。問題は、Python アプリケーションを強制終了すると、bash スクリプトによって生成されたプロセスがラウンドロビン方式でポートを引き継ぎ始めることです。

更新 3:「pstree」と「ps -axf」から見た出力に基づくと、プロセス 1 と 2 (redis サーバーと、newrelic-admin run-program によって生成された Web アプリ) は、Python Web アプリケーションの子プロセスではありません。 . これにより、Python Web アプリケーションを強制終了したときに、そのアプリケーションが占有しているポートを彼らが引き継ぐことがさらに奇妙になります... 理由を知っている人はいますか?

4

1 に答える 1

0

適切な回答に進む前に、上記の問題を解決しようとした方法の背景をいくつか示します。

  1. subprocess.call
  2. subprocess.Popen
  3. 実行する
  4. 上記のいずれかを伴うダブルフォークメソッド（http://code.activestate.com/recipes/278731-creating-a-daemon-the-python-way/）

ちなみに、上記のどれも私にとってはうまくいきませんでした。bash スクリプトを実行する Web アプリケーションを強制終了すると (これにより、バックグラウンド プロセスが生成され、ここでは Q と表記します)、Q 内のプロセスはラウンド ロビン方式で、Web アプリケーションが占有しているポートを引き継ぎます。そのため、Web アプリケーションを再起動する前に、それらを 1 つずつ強制終了する必要がありました。

この問題を抱えて何日も過ごし、プロジェクトの他の部分に移った後、インターネット上のランダムな Stack Overflow の投稿やその他の記事を思いついたのですが、私自身の経験から、リモートに ssh して開始した経験を思い出しました。切断された screen セッションを切断してからログアウトし、しばらくしてから再度ログインして、screen セッションがまだ生きていることを発見します。

だから私は、一体何だ、今のところ何もうまくいかないので、私の問題を解決できるかどうかを確認するために screen を使ってみたほうがいいと思った。そして、私の大きな驚きと喜びに、そうです！したがって、同じ問題に直面している人々を助けるために、このソリューションを投稿しています。

bash スクリプトでは、名前付きの screen プロセスを使用してプロセスを開始しました。たとえば、redis アプリケーションの場合、次のように開始します。

screen -dmS redisScreenName redis-server redis.conf

したがって、これらのプロセスは、開始された切り離された画面セッションで実行され続けます。この場合、redis プロセスをデーモン化しませんでした。

画面プロセスを強制終了するには、次を使用しました。

screen -S redisScreenName -X quit

ただし、これは redis-server を強制終了しません。だから私はそれを別々に殺さなければなりませんでした。

これで、Python Web アプリケーションで subprocess.call を使用して bash スクリプトを実行できます。これにより、スポーンしたいプロセスを実行する切り離されたスクリーン セッションが (「screen -dmS」を使用して) スポーンされます。そして、Python Web アプリケーションを強制終了すると、生成されたプロセスはいずれもそのポートを引き継ぎません。すべてがスムーズに機能します。

于 2013-06-06T04:58:54.873 に答える