3

私はランチャー アプリケーションを作成する予定でしたが、生成された Python プロセスからサブプロセスを完全に切り離す方法が見つかりませんでした。

デスクトップの（シナモンの）ランチャーでプログラムを起動すると、プロセスツリーは次のようになります。

/sbin/init-> mdm-> mdm-> cinnamon-session-> cinnamon->the-app-i-launched

私が読んだスレッドの中で、これが最も洞察に富み、役に立ちました:完全に独立したプロセスを起動します。しかし、OP が Python コードを実行しようとしているため、曖昧な回答が得られます。これは、独立したプロセスを生成するよりも、多くの通常好まれる方法で達成できることがよくあります。

デタッチされたpythonプロセスを起動する方法に答えないスタックオーバーフローからの他の投稿から：

  • デーモン化されたpythonコードの実行 : python インスタンスから切り離された (別のプロセス/アプリケーションではなく) デーモンとしてのpython コード/モジュールの実行に適用されます。
  • subprocess.call : プロセスは python プロセスの子として生成されます。
  • os.system : プロセスは python プロセスの子として生成されます。
  • close_fds : (どうやら) Windows(R) 専用のソリューションで、移植可能なソリューションが必要です (主なターゲットは Debian Linux)。Linux で使用しようとするとclose_fds=True、プロセスは python プロセスの子として生成されます。
  • creationflags : Windows(R) 専用のソリューション。Linux の場合: ValueError: creationflags is only supported on Windows platforms.
  • プレフィックス起動プロセスnohup: プロセスは python プロセスの子として生成されます。私の知る限り、nohupまたは同等のものはすべてのプラットフォームで利用できるわけではないため、Linux のみのソリューションになっています。
  • os.fork : 「デーモン化された Python コードの実行」と同じ。
  • multiprocessing : 「デーモン化された python コードの実行」と同じ問題: python コード/モジュールの実行にのみ役立ちます。
  • os.spawnl* + os.P_NOWAIT : 非推奨の関数を新しいコードに使用することは望ましくありません。私のテストでは、プロセスが実際に生成されたことをまったく確認できませんでした。
  • os.spawnl* + os.P_DETACH : Windows(R) のみ、現在の python 2.X バージョンでは削除されているようです:AttributeError: 'module' object has no attribute 'P_DETACH'.
  • os.system + shell fork : これにより、プロセスが python プロセスから切り離されて実行されているのを実際に見ることができましたが、問題があるのではないかと心配しています:
    • シェルでコマンドを実行することに依存していますが、意図的かどうかに関係なく、悪意に対してより脆弱ですか? .
    • 非移植性に依存していますか？POSIX/シェル? Linux 以外のプラットフォームでは相互に浸透しない可能性のある構文。Partial Refの移植性に関する良いリファレンスを掘り下げていません。
  • subprocess.Popen Alt : サブプロセスが python プロセスの子として実行されていることだけを確認しました。
4

2 に答える 2

-1

私が持っている唯一の実行可能な解決策は、移植性のない Linux のみである可能性があり、shell-detach-ampersand 構文でシェル評価を使用することです。

#!/usr/bin/env python2
import os

os.system('{cmd} &'.format('firefox'))

ただし、これはウィンドウ マネージャー セッションの外でプロセス ツリーを上に行きすぎて、デスクトップ セッションで終了しない可能性があります。

/sbin/init->firefox

于 2015-08-02T22:43:05.740 に答える