有些程序有 --daemonize 选项在后台运行，例如 php-fpm。我想知道使用 --daemonize 或仅使用旧的 & 方式在后台运行进程之间有什么区别吗？
我认为否则为什么要费心提供 --daemonize，为什么不直接用 & 运行它
但我找不到这方面的信息。例如，我测试 php-fpm --daemonize 与 php-fpm & 并做了一些有限的测试。我看不出有什么区别。
- - - 更新 - - -
当我尝试使用 Dockerfile CMD shell 与 exec 形式时，我再次遇到了这个问题。
所以也许值得在这里添加一个SO讨论https://stackoverflow.com/questions/42805750/dockerfile-cmd-shell-versus-exec-form
答案1
&是 shell 语法：shell 在后台启动程序，然后对其进行监视（例如，您可以使用wait然后等待后台进程完成）。因此，您需要使用 shell 才能使其工作，但这可能并非在所有情况下都是可取的或不可能的。
--daemonize类似的选项由程序本身处理（它可能会做双叉和setsid将自己与启动它的任何东西分离出来），因此它们与启动程序的其他方式一起工作（例如，C 中的 fork-and-exec）。
您想要使用哪个可能取决于您打算如何启动程序以及您希望程序稍后处于什么状态。
举一个不寻常的例子sudo。如果您想sudo在后台运行命令，但需要进行身份验证，则运行时无法提供密码sudo foo bar &。当然，一种方法是首先使用不执行任何操作的命令 或 进行身份验证-v，然后依靠 sudo 超时来运行实际命令，而&无需第二次输入密码。另一种方法是在前台运行它，然后使用CtrlZ和将其发送到后台bg。但是，sudo有一个--background选项，它将在前台运行，要求输入密码，然后进行守护进程（但随后您不能在其上使用 shell 的作业控制）。
还有其他副作用。例如，当使用&bash 在后台运行程序时，如果作业控制未激活（脚本中的默认设置），则/dev/null新进程的标准输入将设置为。对于诸如 之类的选项--daemonize，程序可以决定如何处理它继承的标准输入。