一部のプログラムには、php-fpmなど、バックグラウンドで実行される--daemonizeオプションがあります。 --daemonizeを使用することと、バックグラウンドでプロセスを実行する既存の方法を使用することとの間に違いがあるかどうか疑問に思います。
私がそうでなければ、なぜ --daemonize を提供しなければならないのか、なぜ&を使って実行しないのかと思います。
しかし、これに関する情報が見つかりません。たとえば、私はphp-fpm＆でphp-fpm --daemonizeをテストし、いくつかの制限されたテストを実行しました。私は違いを見ることができません。
- - - 更新 - - -
Dockerfile CMD シェルを exec 形式で使用しようとすると、この問題が再発生しました。
たぶんここにSOディスカッションを追加する価値があるでしょう。https://stackoverflow.com/questions/42805750/dockerfile-cmd-shell-versus-exec-form
ベストアンサー1
&シェル構文は次のとおりです。シェルはバックグラウンドでプログラムを起動し、それを監視します（たとえば、waitバックグラウンドプロセスを使用して完了するまで待つことができます）。したがって、これを機能させるにはシェルを使用する必要がありますが、すべての場合にこれが望ましくない可能性はありません。
--daemonize同様のオプションはプログラム自体で処理されます。ダブルクロスとsetid開始されたすべてのものから自分で分離されるので、プログラムを起動する他の方法（例えば、Cの分岐や実行）と連携します。
どのようなものを使用したいのかは、プログラムの起動方法と、後でプログラムをどの状態にするかによって異なります。
珍しい例を見てくださいsudo。sudoバックグラウンドでコマンドを実行したいが認証が必要な場合は、実行時にパスワードを提供できませんsudo foo bar &。もちろん、1つのアプローチは、最初に何も実行しないか、認証を実行しないコマンドを-v使用してから、sudoタイムアウトを使用して&2番目のパスワードを入力することなく実際のコマンドを実行することです。もう1つの方法は、フォアグラウンドで実行してから、およびを使用してCtrlZバックグラウンドに送信することですbg。ただし、フォアグラウンドで実行し、パスワードを要求してからデーモン化するオプションがsudoあります（ただし、この場合、シェルのジョブ制御は使用できません）。--background
他の副作用もあります。たとえば、&bashを使用してバックグラウンドでプログラムを実行してもジョブ制御が有効になっていない場合（スクリプトのデフォルト）、/dev/null新しいプロセスの標準入力はに設定されます。などのオプションを使用すると、--daemonizeプログラムは継承した標準入力の処理方法を決定できます。