我的脚本（位于/etc/init.d）正在创build一个pid文件（$ PIDFILE），但是没有进程正在运行。 我的守护脚本包括：
start-stop-daemon --start --quiet --pidfile $PIDFILE -m -b --startas $DAEMON --test > /dev/null || return 1 该脚本手动执行时工作正常。
您需要创建启动链接 。
sudo update-rc.d SCRIPT_NAME defaults
然后重启。 SCRIPT_NAME是/etc/init.d脚本的名称（没有路径）
能够得到它的工作，但尝试了很多东西，不知道究竟是什么修复它（可能是在脚本或配置错误）。 然而，由于在互联网的深渊中找不到相同的东西，我学到了很多，想要分享。
看来Ubuntu（以及包括Mint在内的许多其他基于Ubuntu的发行版）已经迁移到Upstart进行作业和服务管理。 Upstart包括SysVinit（使用/etc/init.d守护进程）兼容性，仍然可以使用update-rc.d来管理守护进程（所以如果你熟悉这个用法，你可以继续使用它）。 Upstart方法是在/ etc / init文件夹中使用一个.conf文件。 我的SCRIPT.conf文件非常简单（我正在使用python脚本）：
start on filesystem or runlevel [2345] stop on runlevel [016] exec python /usr/share/python-support/SCRIPT/SCRIPT.py
这个简单的文件完全用case语句替换/etc/init.d中的标准脚本，以提供[start | stop | restart | reload]函数和指向/ usr / bin / SCRIPT的指针。 你可以看到它包含了通常在/etc/rc*.d文件中找到的runlevel控件（这样就省去了几个文件）。
我尝试update-rc.d为我的守护进程创建必要的/etc/rc*.d/文件。 我的守护程序bash脚本位于/etc/init.d中，包含start-stop-daemon命令，就像我原来的问题一样。 （该命令也可以从终端正常工作。）
我有/etc/rc*.d/文件，/etc/init.d和/etc/init/SCRIPT.conf文件中的bash脚本在启动过程中，似乎Upstart可能会首先查找.conf文件的方向因为SysVinit命令service SCRIPT [start|stop|restart|reload]返回未知实例，但是您可以发现进程正在运行ps -elf | grep SCRIPT_FILE ps -elf | grep SCRIPT_FILE 。
有一件有趣的事情要注意，使用.conf时，守护进程是分叉的。 上面写的脚本只产生守护进程的一个分支。 然而，原始脚本的完全独立性可以通过使用expect fork或expect daemon和respawn （参见Upstart Cookbook以供参考）。 使用这些将确保您的守护进程永远不会被杀死（至少通过使用kill命令）。
我继续使用sudo initctl reload-configuration命令来测试我的守护进程和启动进程。 这会重新载入conf文件，你可以用sudo [start|stop|restart] SCRIPT命令测试守护进程。 启动命令的结果是：
$ sudo start SCRIPT SCRIPT start/running, process xxxx $ sudo restart SCRIPT SCRIPT start/running, process xxxx $ sudo stop SCRIPT SCRIPT stop/waiting
此外，/var/log/upstart/SCRIPT.log中还有一个很好的日志，可以在启动过程中为守护进程提供有用的信息。 我仍然有一个非常恼人的错误，防止根显示osd消息通知发送从我的守护进程。 我的日志文件包含一个gtk警告（我将打开另一个问题来请求帮助）。
希望这有助于他人开发他们的守护进程。