Question

我的脚本（位于/etc/init.d）正在创建一个pid文件（$ PIDFILE），但没有进程正在运行。我的守护程序脚本包括：

start-stop-daemon --start --quiet --pidfile $PIDFILE -m -b --startas $DAEMON --test > /dev/null || return 1

手动执行时脚本运行正常。

Answer 1

您需要create startup links。

sudo update-rc.d SCRIPT_NAME defaults

然后重启。 SCRIPT_NAME是/etc/init.d（没有路径）

中脚本的名称

Answer 2

能够让它工作，但尝试了很多东西，不知道究竟修复了什么（可能是脚本或配置中的错误）。但是，我学到了很多东西，并希望分享，因为我在互联网深渊中找不到相同的东西。

似乎Ubuntu（以及许多其他基于Ubuntu的发行版，包括Mint）已迁移到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

这个简单的文件完全取代/etc/init.d中的标准脚本和case语句，以提供[start | stop | restart | reload]函数和指向/ usr / bin / SCRIPT的指针。您可以看到它包含通常位于/etc/rc*.d文件中的运行级控件（从而消除了多个文件）。

我尝试使用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。

需要注意的一件有趣的事情是在使用.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，可以在启动时为您的守护程序提供有用的信息。我仍然有一个非常烦人的错误，它阻止root用我的守护进程发送带有notify-send的osd消息。我的日志文件包含一个gtk警告（我将打开另一个问题来征求帮助）。

希望这有助于其他人开发他们的守护进程。

脚本无法在启动时使用start-stop-daemon启动

2 个答案: