【APUE】Chapter13 Daemon Processes

这章节内容比较紧凑，主要有5部分：

1. 守护进程的特点

2. 守护进程的构造步骤及原理。

3. 守护进程示例：系统日志守护进程服务syslogd的相关函数。

4. Singe-Instance 守护进程。

5. 其他相关内容

1. 守护进程的特点

　　守护进程也是unix系统中的一种进程。有大量的系统守护进程，其最主要的特点有两个：

　　（1）系统启动的时候守护进程就跟着起来；只有当系统关闭的时候守护进程才跟着关闭

　　（2）没有controlling terminal，运行在background

　　直观上，可以用ps(1)命令先去查看各种进程，执行ps -efj > o （结果重定向到文件里方便处理）

　　e(every)代表所有进程；f(full)代表现实全部信息；j(job)job模式，结果如下图：

　　【APUE】Chapter13 Daemon Processes-LMLPHP

　　（1）/sbin/init是一个user-level的守护进程，系统启动的时候kernel让它跟着起来

　　（2）带中括号的进程都是kernel级别的进程，kernel process跟着系统一起起来执行周期是entire lifetime；而且这些进程没有controlling terminal & command line，正经的Daemon Processes

　　（3）其中[kthread]是'kernel的kernel'，其他的kernel来产生其他的kernel进程，这一点从其他kernel进程的PPID就能够看出来（kthread的PID是2，其余的kernal processes的PPID都是2）

　　除了kernel process还有一些常见的非kernel的daemons processes，比如xinted(监听网络服务)，crond(定时任务)，sshd(远程链接)，rsyslogd(系统日志服务)等

　　【APUE】Chapter13 Daemon Processes-LMLPHP

　　（1）注意到这些守护进程，大都是有root权限的；而且TTY的选项都是'?' (即没有controlling terminal)。

　　（2）这些非kernel的daemon processes的parent process都是init进程

　　（3）除了rsyslogd之外，一般的daemon processes都是独占session和process group，并且都是leader。在这个方面rsyslogd算是一个特例，后面单独拎出来讲rsyslogd。

2. 守护进程的构造步骤及原理

　　系统自带了大量的守护进程，如果我们要自己构建一个守护进程，需要按照特定的方式一步步来完成。

　　先上一个代码（并非书上的例子，而是stackoverflow找的http://stackoverflow.com/questions/17954432/creating-a-daemon-in-linux）

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <syslog.h>

static void skeleton_daemon()

{

    pid_t pid;

    pid = fork(); // 1. fork off the parent process

    if (pid < ) {

        exit(EXIT_FAILURE);

    }

    if (pid > ) { // 1. terminates the parent process

        exit(EXIT_SUCCESS);

    }

    if (setsid()<) { // 2. child process becomes session leader

        exit(EXIT_FAILURE);

    }

    signal(SIGCHLD, SIG_IGN);

    signal(SIGHUP,SIG_IGN);

    pid = fork(); // 3. fork off the second time

    if (pid<) {

        exit(EXIT_FAILURE);

    }

    if (pid>) { // terminates the parents

        exit(EXIT_SUCCESS);

    }

    umask(); // 4. set new file permissions

    chdir("/"); // 5. change the working directory

    int x; // 6. close all open file descriptors

    for (x=sysconf(_SC_OPEN_MAX); x>; x--)

    {

        close(x);

    }

    openlog("firstdaemon", LOG_PID, LOG_DAEMON);

}

int main()

{

    skeleton_daemon();

    while ()

    {

        syslog(LOG_NOTICE, "First daemon started.");

        sleep();

        break;

    }

    syslog(LOG_NOTICE, "First daemon terminated.");

    closelog();

    return EXIT_SUCCESS;

}

　　　按照上述代码的注释中的标号（代码注释中的标号对应着下面分析的标号）& APUE Chapter 13.3的内容，分析如下（要想看懂上面的代码，必须有APUE前面章节关于fork和进程的知识）：

　　（1）构造孤儿进程

　　　　　　做第一次fork，结束parent process，留下child process；这样留下的child process就成了孤儿进程。

　　　　　　为什么要做这一步呢？

　　　　　　构造孤儿进程的目的：后续构建步骤要调用setsid()，而调用setsid()的进程要求必须不是process group leader，孤儿进程肯定不是group leader

　　（2）脱离原来的session

　　　　　　就是一句调用setsid()就可以了，产生了一个新的session。

　　　　　　为什么要做这一步呢？

　　　　　　回顾APUE（英文原版）P295上的内容，当非process group leader调用setsid()的时候会产生如下的作用：

　　　　　　a. 这个孤儿进程成为了新的session的唯一进程，并且也是session leader

　　　　　　b. 这个孤儿进程成为了所在process group的leader

　　　　　　c. 这个孤儿进程没有相对应的controlling terminal

　　　　　　这一步的原因就是，新产生的session是没有controlling terminal的，这个是daemons process要求的

　　（3）* 再次构造孤儿进程

　　　　　　做第二次fork，结束parent process，留下child process；这样上次刚刚调用setsid()函数的进程，由产下第二个孤儿进程。

　　　　　　为什么要做这一块呢？

　　　　　　在（2）中，通过setsid()已经让进程所在的session没有了controlling terminal，按理说是是符合daemon的要求了；但是某些条件下，系统会给这些没有controlling terminal的进程 “allocating the controlling terminal for a session”。

　　　　　　回顾APUE书上P297中Controlling Terminal的部分，上面说的“某些条件下”包括：

　　　　　　a. 首先这个process是session leader

　　　　　　b. "这个process调用了open，并且没有设定O_NOCTTY flag"或"调用了ioctl函数"

　　　　　　简单来说，只要一个process虽然所在的session是没有controlling terminal的；但是只要这个process是session leader，那么还是有可能在某种情况下被触发，让系统给其分配controlling terminal，打破了daemon process的禁区。

　　　　　　这一步骤，在APUE书上并不是必须的，但是既然说的有道理，就应该当成是一个必须的步骤。

　　（4）设置文件权限

　　　　　　unmask(0)，这个不太明白，先记个“权限”

　　（5）修改进程工作的目录

　　　　　　由于child process的工作目录是从parent process中继承获得的，修改工作目录，给process增加“权限”

　　（6）关闭所有的file descriptors

　　　　　　这个也是从parent process继承过来的，但是daemon process并不需要。

　　　　　　daemon process不能与stdout stderr stdin发生交互；所以如果之前有打开的，就必须给关上才行。

　　代码编译运行后，在终端并没有什么输出。

　　执行ps xj，结果如下：

　　【APUE】Chapter13 Daemon Processes-LMLPHP

　　可以看到a.out的PPID是1（归init管了）；TTY是‘？’（没有controlling terminal了）；SID PGID都是一样的；但是PID与PGID不一样（这就是第二次fork的作用，不是session leaders了，不会触发某些条件使得所在session被allocating controlling terminal了）。

　　一个daemon process的例子就完成了。

3. 系统日志守护进程服务：syslogd及其相关函数

　　我们检查一下/var/log/messages文件（需要root权限），发现多了如下的两行：

　　【APUE】Chapter13 Daemon Processes-LMLPHP

　　我们关注2中main函数中的代码：

int main()

{

    skeleton_daemon();

    while ()

    {

        syslog(LOG_NOTICE, "First daemon started.");

        sleep();

        break;

    }

    syslog(LOG_NOTICE, "First daemon terminated.");

    closelog();

    return EXIT_SUCCESS;

}

　　main的开始先调用skeleton_daemon()构建了一个daemon process；后面syslog函数中包含输出结果中的文本；这个过程中发生了什么？

　　（1）首先说一下motivation。回顾1中提到的daemon process的特点：没有controlling terminal，不能写到标准输入输出中。那么如果daemon process出了问题，或者想输出一些log信息便于调试该怎么办？那么多的daemon process存在，总不能来一个daemon process就制定一个separate file作为输出的容器吧。更好的做法是把daemon process统一管理起来，于是就产生了上面提到的一种专门负责日志输出的daemon process，就是rsyslogd。

　　（2）系统已经提供了rsyslogd服务来处理日志，那么我们只需要学会调用就可以了。具体的流程图如下（P469）：

　　【APUE】Chapter13 Daemon Processes-LMLPHP 　　

　　通过上面的流程图，我们对发生了什么可以了解个大概：

　　　　a. 在main中调用syslog函数

　　　　b. 调用kernel中的unix domain datagrom socket相关的内容

　　　　c. 再调用rsyslogd服务，完成了日志内容的输出

　　再由上图的内容，扩展一下unix系统处理日志输出的kernel框架：

　　　　a. 有一个分支专门管kernal routines的输出的

　　　　b. 有一个分支专门管TCP/IP network来的

　　　　c. 处理user process中各种log需求的（最左边的）

　　（3）了解了大致流程后，我们看openlog和syslog函数的具体参数。

　　　　openlog(const char *ident, int option, int facility)

　　　　ident : 用于标示是哪个程序产生的，一般都用程序的名；在上面的例子中就是"firstdaemon"

　　　　option : 书上写的也比较模糊，直接man openlog查看，如下：