在初始化脚本的上下文中，根据LSB规范 ，“每个符合的初始化脚本必须执行文件/ lib / lsb / init-function中的命令”，然后在使用守护进程时定义了一些函数。 其中一个函数是start_daemon ，它明显地“运行指定的程序作为后台进程”，同时检查守护进程是否已经在运行。
我正在为我的一个服务应用程序进行守护进程，而且我正在研究其他守护进程如何运行以尝试“适应”。 在看看它在别处如何完成的过程中，我注意到我的Ubuntu 10.04机器上没有一个守护进程使用start_daemon。 他们都直接调用start-stop-daemon。 我的Fedora 14机器也一样。 我是否应该尝试打好，成为第一个使用start_daemon的人，还是真的没有什么意义，因为每个人都已经在使用start-stop-daemon了。 为什么没有使用LSBfunction的守护进程？
在我的系统上，大多数脚本使用start-stop-daemon ，但exim4和incron使用start-daemon 。
如果您想编写脚本以实现可移植性并遵守LSB，请使用start_daemon 。 在Ubuntu上，它是作为start-stop-daemon的简单包装来实现的。
如果需要start-stop-daemon提供的参数粒度，请使用它。
在Debian（以及Ubuntu）上， lsb-base软件包有自述文件（位于/usr/share/doc/lsb-base/README.Debian.gz ）：
注意：Debian软件包可能应该直接使用start-stop-daemon; 但是，这些函数可能会在从其他发行版移植init脚本时很有用。
所以，专门为Debian打包的软件通常使用start-stop-daemon 。 我可以想象，从另一个系统移植的软件可能会使用start_daemon ，但是如果其他系统有类似的策略，那么软件首先不会使用start_daemon ，所以使用start_daemon移植它可能不会比start-stop-daemon 。 我也可以想象，为许多系统打包的软件可能会使用start_daemon来启用可移植的init脚本。 Exim可能就是一个很好的例子。
就我个人而言，我认为自述的build议是可怕的，与犯罪行为接壤。 我们有一个标准; 如果每个人都坚持下去，那么软件将会更加便携，这是件好事。 build议人们不要使用标准传递机会，让世界变得更美好。