在 init 脚本中，根据LSB 规范, “每个符合要求的 init 脚本都应执行文件 /lib/lsb/init-function 中的命令”，然后定义了使用守护进程时要使用的几个函数。其中一个函数是start_daemon，它显然“将指定的程序作为守护进程运行”，同时检查守护进程是否已在运行。
我正在对我的一个服务应用程序进行守护进程化，并且正在查看其他守护进程的运行方式，以尝试“融入”。在查看其他地方的运行方式的过程中，我注意到我的 Ubuntu 10.04 机器上没有一个守护进程使用 start_daemon。它们都直接调用 start-stop-daemon。我的 Fedora 14 机器也是如此。我应该尽量表现得友好，成为第一个使用 start_daemon 的人吗？或者真的没有意义，既然每个人都已经在使用它，start-stop-daemon 才是最佳选择？为什么没有守护进程使用 LSB 的功能？
答案1
在我的系统上，大多数脚本使用start-stop-daemon，但两个exim4和incron使用start-daemon。
如果您希望编写可移植性脚本并遵守 LSB，请使用start_daemon。在 Ubuntu 上，它是作为 的简单包装器实现的start-stop-daemon。
如果您需要 提供的参数粒度start-stop-daemon，请使用它。
答案2
在 Debian (当然，Ubuntu) 上，该lsb-base软件包的自述文件 (at /usr/share/doc/lsb-base/README.Debian.gz) 中写道：
注意：Debian 软件包可能应该直接使用 start-stop-daemon；但是，这些功能在从其他发行版移植初始化脚本时可能会很有用。
因此，专门为 Debian 打包的软件通常使用start-stop-daemon。我可以想象从其他系统移植的软件可能会使用start_daemon，尽管如果其他系统有类似的策略，那么软件start_daemon首先就不会使用 ，因此使用 移植它可能不会比 更容易start_daemon。start-stop-daemon我还可以想象为许多系统打包的软件可能会使用start_daemon，以启用可移植的 init 脚本。Exim 可能就是一个很好的例子。
就我个人而言，我认为自述文件中的建议很糟糕，近乎犯罪。我们有一个标准；如果每个人都遵守它，软件将更具可移植性，这是一件好事。建议人们不要使用该标准会错失让世界变得更美好的机会。