使用 & 與 –daemonize 選項在後台執行程序有什麼區別嗎？
一些程序有 –daemonize 選項可以在後台執行，例如 php-fpm。我想知道使用 –daemonize 或僅使用舊的 & 方式在後台執行程序之間有什麼區別？
我認為否則為什麼要費心提供–daemonize，為什麼不直接用&執行它
但我找不到有關這方面的資訊。例如，我測試 php-fpm –daemonize vs php-fpm & 並做一些有限的測試。我看不出有什麼區別。
- 更新 - - -
在嘗試 Dockerfile CMD shell vs exec 表單時，我再次遇到了這個問題。
所以也許值得在這裡添加一個 SO 討論https://stackoverflow.com/questions/42805750/dockerfile-cmd-shell-versus-exec-form
&是shell 語法：shell 在後台啟動程序，然後對其進行監視（例如，您可以使用waitto 然後等待後台程序完成）。因此，您需要使用 shell 才能使其工作，這在所有情況下都可能不是可取的或可能的。
--daemonize並且類似的選項由程序本身處理（它可能會執行雙叉和 setid以將自己與啟動它的任何東西分離），因此它們可以與其他啟動程序的方式一起使用（C 中的 fork-and-exec，例如例子）。您要使用哪個可能取決於您打算如何啟動程序，以及您希望程序稍後處於什麼狀態。
舉一個不尋常的例子，以
sudo. 如果您想sudo在後台執行命令，但需要進行身份驗證，則執行時無法提供密碼sudo foo bar &。當然，一種方法是首先使用無操作命令或 進行身份驗證-v，然後依靠 sudo 超時執行實際命令，&而無需第二次輸入密碼。另一種是在前台執行它，然後使用Ctrl``Zand將其發送到後台bg。但是，sudo有一個--background選項，它將在前台執行，詢問密碼，然後守護程序（但是你不能使用 shell 的作業控制）。還有其他副作用。例如，當使用
&in bash 在後台執行程序時，如果作業控制未啟動（如腳本中的預設設置），/dev/null則為新程序設置標準輸入。使用類似--daemonize的選項，由程序決定如何處理它繼承的任何標準輸入。