6、守护进程遵循的一些标准

Unix上面的守护进程，一般会遵循如下的通用标准：

1. 如果守护进程使用锁文件，那么锁文件一般会存放在/var/run目录下面。这里我们需要注意的是，我们需要拥有超级用户权限才能在这里面创建文件。创建的文件名称一般就是<name>.pid，这里的<name>就是守护进程的名称,例如crond守护进程的锁名称就是/var/run/crond.pid。
2. 如果守护进程支持配置选项，那么它们一般存放在/etc目录下面。配置文件的名称就是<name>.conf，这里<name>就是守护进程或者服务的名称,例如syslogd守护进程的名称就是/etc/syslog.conf。
3. 守护进程可以从命令行启动,但是它们一般都从某个系统初始化脚本中启动（/etc/rc*或者etc/init.d/*），如果守护进程在退出的时候应该自动重新启动，那么我们可以修改init程序的配置文件/etc/inittab的相关条目（加上respawn），让init程序来做这个工作。
4. 如果守护进程具有一个配置文件，那么守护进程在启动的时候会读取它，但是之后就不会再次读取它了。如果管理员修改了配置，那么需要重新启动这个守护进程才能让新配置起作用。对于此情况，有些守护进程会捕获SIGHUP信号，并且在收到这个信号的时候会重新读取它们的配置文件。因为守护进程并不和终端关联，并且是没有控制终端的session leader或者孤儿进程组的一员，所以信号SIGHUP对于守护进程来说是没有什么意义的，所以可以通过这种方式来重新利用这个信号。

举例：这里也给出了一个例子来展示一个守护进程如何重新读取它的配置文件。程序使用sigwait和多线程技术实现这个功能，具体例子代码就不给出了，请参见参考资料。后面只对这个例子进行一下简单的说明。

我们先调用前面的daemonize函数（将一个进程变成守护进程的函数）对守护进程进行初始化，当这个函数返回的时候，我们调用already_running（判断这个守护进程是否只有一个实例在系统中运行）。这个时候，SIGHUP信号还是处于忽略的状态，所以我们需要把这个信号的处理动作重新设置成默认的行为；否则调用sigwait(线程用来等待特定信号的函数，具体前面讲过)的线程就无法看到这个信号了。

我们按照多线程编程的一些合理性建议，把所有的信号都阻塞，然后创建了一个独立的线程来处理信号。这个线程的唯一工作就是等待SIGHUP和SIGTERM信号，当它收到SIGHUP信号的时候，线程会调用reread函数来重新读取配置文件。当线程收到SIGTERM信号的时候，它会登记一个消息并且退出。

前面讲过，SIGHUP和SIGTERM信号的默认行为就是终止一个进程。因为我们阻止了这些信号，所以当它们发生的时候，守护进程并不会终止。相反，调用sigwait的线程会返回一个状态来标记这个信号被接收到了。

又一个例子：如前面所说，Linux的线程对信号的反应有点不同，因此前面的例子中要想给合适的进程发送信号是比较困难的。另外，由于实现的不同，我们也不能保证守护进程的表现将会和我们期望的那样。

这里的另外一个例子展示了一个守护进程如何捕获SIGHUP信号并且在不使用多线程的情况下重新读取它的配置文件。这里也不给出具体的代码了，详细可以参见参考网址。

初始化完了守护进程之后，我们安装了SIGHUP和SIGTERM信号。我们把重新读取的逻辑放到信号处理函数中执行(本例子就是这样的)，或者在信号处理函数中设置一个标记，然后在程序的主线程中做相应的工作。

译者注

原文参考

参考： APUE2/ch13lev1sec6.html