私は *nix を使い始めたばかりですが、100% の時間で実行する必要がある複数のプロセスを、 を使用してバックグラウンドにドロップする必要に迫られました&
。
これを実行するには、init.d スクリプトで次の行を使用します (ユーザーとして実行) user
。
su -c 'process arg1 arg2 -w - | process2 arg1 -r - &' user
(-w は STDOUT、STDIN に書き込み、-r はそこから読み取ります)
具体的には、プロセスが外部の影響から十分に保護されていないため、これは一般的に受け入れられないことを知っています。
「サービス」のバックグラウンドジョブを作成することは許容されますか?
プロセス間通信を処理するために、代わりに FIFO/名前付きパイプを使用する必要がありますか?
もしそうなら、両方のプロセスをバックグラウンド ジョブとして作成する必要がありますか? これは安定していますか?
詳細については、このメーリングリストのスレッド。
ありがとう、
マット
答え1
具体的には、プロセスが外部の影響から十分に保護されていないため、これは一般的に受け入れられないことを知っています。
「サービス」のバックグラウンドジョブを作成することは許容されますか?
他に方法がない場合 (つまり、サービスが独自にフォークしない場合)、おそらくはい。Debian には、このような場合のためのパラメータstart-stop-daemon
があります。--background
-b, --background
Typically used with programs that don't detach on their own.
This option will force start-stop-daemon to fork before starting
the process, and force it into the background. WARNING:
start-stop-daemon cannot check the exit status if the process
fails to execute for any reason. This is a last resort, and is
only meant for programs that either make no sense forking on
their own, or where it's not feasible to add the code for them
to do this themselves.
答え2
最初の質問にはすでに答えが出ているので、最後の質問の両方に集中します。
数日前、私は似たような問題に悩まされました。スクリプトからパイプ経由でいくつかのプロセスを開始する必要がありました。これを解決するために、RHEL6 (および) と Debian ( )/etc/init.d
を調べました。私が学んだのは、どちらもパイプを (あまりうまく) 処理できないということでした。何とか開始できたとしても、停止するには大きな問題がありました。そこで、私は小さなツールを書きました。daemon
killproc
/etc/init.d/functions
start-stop-daemon
pipexec
このプログラムは、プログラムのパイプを開始しますが、1 つのプログラムのように動作します。例: がSIGTERM
に送信されると、すべての子を終了し、その後、それ自体を終了します。また、pid ファイル処理もサポートされているため、RHEL6およびpipexec
と統合するときに簡単に実行できます。daemon
killproc
プロセス間通信を処理するために、代わりに FIFO/名前付きパイプを使用する必要がありますか? その場合、両方のプロセスをバックグラウンド ジョブとして作成する必要がありますか? これは安定していますか?
私もこれについて考えましたが、私にとっては複雑すぎるし、安定性と信頼性に関して FIFO に関してはあまり良い経験がありませんでした (これが私の問題かもしれませんが、そのため私はめったに FIFO を使用しません ;-) )
RHEL6 と統合しましたpipexec
が、問題なく実行できました。
よろしくお願いいたします - アンドレアス