linux守护进程、SIGHUP与nohup详解

前段时间帮忙定位个问题。docker容器故障恢复后，其中的keepalived进程始终无法启动，也看不到Keepalived的日志。

strace 查看系统调用之后，发现了原因所在

socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/var/run/keepalived.pid", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe85ab1b000
read(3, "\n", 4096)                     = 1
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7fe85ab1b000, 4096)            = 0
kill(0, SIG_0)                          = 0
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

这就是一个典型的linux单例守护进程启动做的事情：检测进程是否已经存在（判断记录文件是否存在以及对应pid进程是否还在执行），并通过syslog套接字文件向syslog服务端发送日志。

很显然，Keepalived无法正常启动是故障宕机时，相应的pid文件没有清理干净，如果仅仅如此，Keepalived应该可以启动，一般守护进程启动都会覆盖残留的锁文件，问题关键在read(3, "\n", 4096) ： 锁文件Keepalived.pid是空的！！ 而kil 向进程0 发送信号0，执行成功，则Keepalived认为已经有Keepalived进程正在运行。所以问题出在锁文件存在且内容为"\n"，故依次清理 keepalived.pid vrrp.pid checkers.pid文件后，Keepalived正常启动。至于定位为何锁文件内容为"\n"，那是后话了。

经此一事，笔者想写一写Linux 守护进程

守护进程特点与相关概念

并非运行时间长的程序即是守护进程，笔者并未找到守护进程最标准的定义，但守护进程都有下面几个特点：

1、没有控制终端，终端名设置为？号：也就意味着没有 stdin 0 、stdout 1、stderr 2

2、父进程不是用户创建的进程，init进程或者systemd（pid=1）以及用户人为启动的用户层进程一般以pid=1的进程为父进程，而以kthreadd内核进程创建的守护进程以kthreadd为父进程

3、守护进程一般是会话首进程、组长进程。

4、工作目录为 \ （根），主要是为了防止占用磁盘导致无法卸载磁盘

 

这里涉及到一些概念，是unix为了更好管理进程间的关系提出的概念和方法，稍做说明下

控制终端

通过网络登录或者终端登录建立的会话，会分配唯一一个tty终端或者pts伪终端（网络登录），实际上它们都是虚拟的，以文件的形式建立在/dev目录，而并非实际的物理终端。

在终端中按下的特殊按键：中断键（ctrl+c）、退出键（ctrl+\）、终端挂起键（ctrl + z）会发送给当前终端连接的会话中的前台进程组中的所有进程

在网络登录程序中，登录认证守护程序 fork 一个进程处理连接，并以ptys_open 函数打开一个伪终端设备（文件）获得文件句柄，并将此句柄复制到子进程中作为标准输入、标准输出、标准错误，所以位于此控制终端进程下的所有子进程将可以持有终端

与控制终端相连的会话首进程也叫控制进程

进程组

进程组是一个或者多个进程的集合。一般由某个程序fork出一个家族来构成进程组，或者由管道命令建立作业构成进程组。

同一个进程组中的所有进程接收来自同一终端的信号。

进程组中的第一个进程作为进程组的首长，进程组id取首长进程的id。在各个进程中，通过函数getpgrp获取其所属进程组id

孤儿进程组

一个进程的父进程终止后，进程变成了孤儿进程，将被pid为1的进程（init进程或者systemd）收养。

而对孤儿进程组的定义是：进程组中每个进程的父进程要么在组中，也么不在该组所在会话中。

换言之，如果一个进程组中进程的父进程如果是组中成员，或者是init、systemd进程的话，这个进程组就一定是孤儿进程组。这样的进程组是很常见的，下图就是一个简单且典型的孤儿进程组

很显然，只有一个进程的进程组，并且是孤儿进程的话，进程组将变成孤儿进程组（哪怕它只有一个进程）。

典型的例子是一个父进程fork子进程之后，父进程立即退出，这样子进程所在的进程组将变为孤儿进程组。这样的孤儿进程组中的每个停止（Stopped）状态的每个进程都将收到挂断信号（SIGHUP），然后又立即收到继续信号（SIGCONT）。所以fork子进程之后，退出父进程，如果子进程还需要继续运行，则需要处理挂断信号，否则进程对挂断信号的默认处理将是退出。

此时的孤儿进程组并没有变为后台进程，一些博客将后台进程说成是孤儿进程组的一个特点，笔者认为是不正确的，在他们的示例中，孤儿进程组变为后台进程的原因是：父进程退出后，子进程在运行时向自身发送了SIGTSTP信号，这就像在终端按下终端挂起键（ctrl+z）一样，暂时断开了进程与控制终端的连接，自然变成了后台进程。

所以这是将进程转到后台运行的一个手段，但并不能创建守护进程，后面会将怎么创建守护进程。

会话

表示一个或多个进程组的集合，在有控制终端的会话中，可以被分为一个前台进程组和多个后台进程组。

取首进程id为会话id。

函数getsid用来获取会话id，而函数setsid用来新建一个会话，只有非首长进程（非进程组的组长）才能调用setsid新建会话。实际上setsid做了三件事

• 设置当前进程的会话id为该进程id，此进程成为会话首进程。
• 将调用setsid的进程设置为一个新进程组的首长进程。
• 断开已连接的控制终端

这三步是创建守护进程的重要步骤。

下图结合了笔者对这些概念的理解，做出的判断

 

守护进程的创建

创建守护进程有标准的步骤：

1. 如果是单例守护进程，结合锁文件和kill函数检测是否有进程已经运行
2. umask取消进程本身的文件掩码设置，也就是设置Linux文件权限，一般设置为000，这是为了防止子进程创建创建一个不能访问的文件（没有正确分配权限）。此过程并非必须，如果守护进程不会创建文件，也可以不修改
3. fork出子进程，父进程退出。这样子进程一定不是组长进程（进程id不等于进程组id）
4. 子进程调用setsid新建会话（使子进程变为会话首进程、组长进程，并断开终端）
5. 如果是单例守护进程，将pid写入到记录锁文件，一般为/var/run/xxx.pid
6. 切换工作目录到根目录，这是为了防止占用磁盘造成磁盘不能卸载。所以也可以改到别的目录，只要保证目录所在磁盘不会中途卸载
7. 重定向输入输入错误文件句柄，将其指向/dev/null。

前面提到，守护进程一般借助记录锁文件来（文件存在并且文件内记录的pid对应的进程依然活跃）判断是否已经有进程存在。

多数守护进程并不自己维护日志文件，而是统一将日志输出给遵循syslog协议的日志进程（如：rsyslogd）处理，统一将日志输出至 /var/log/messages，当然这些日志进程也是可以配置的。

而且守护进程因为是没有终端的后台进程，所以系统不会发送一些跟终端相关的信号给守护进程，程序可以通过捕捉这些只有可能人为发送的信号，来处理一些事情，比如处理SIGHUP来动态更新程序配置就是典型例子。下面的代码演示了如何创建一个守护进程。

#include <stdio.h>
#include <syslog.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/resource.h>

#define PID_FILE "/var/run/sampled.pid"

int sampled_running(){
    FILE * pidfile = fopen(PID_FILE,"r");
    pid_t pid;
    int ret ;

    if (! pidfile) {
        return 0;
    }

    ret = fscanf(pidfile,"%d",&pid);
    if (ret == EOF && ferror(pidfile) != 0){
        syslog(LOG_INFO,"Error open pid file %s",PID_FILE);
    }

    fclose(pidfile);
    
    // 检测进程是否存在
    if ( kill(pid , 0 ) ){
        syslog(LOG_INFO,"Remove a zombie pid file %s", PID_FILE);
        unlink(PID_FILE);
        return 0;
    }

    return pid;
}

pid_t sampled(){
    pid_t pid;
    struct rlimit rl;
    int fd,i;

    // 创建子进程，并退出当前父进程
    if((pid = fork()) < 0){
        syslog(LOG_INFO,"sampled : fork error");
        return -1;
    }
    if ( pid != 0) {
        //  父进程直接退出
        exit(0);
    }

    // 新建会话，成功返回值是会话首进程id，进程组id ，首进程id
    pid = setsid();

    if ( pid < -1 ){
        syslog(LOG_INFO,"sampled : setsid error");
        return -1;
    }

    // 将工作目录切换到根目录
    if ( chdir("/") < 0 ) {
        syslog(LOG_INFO,"sampled : chidr error");
        return -1;
    }

    // 关闭所有打开的句柄，如果确定父进程未打开过句柄，此步可以不做
    if ( rl.rlim_max == RLIM_INFINITY ){
        rl.rlim_max = 1024;
    }
    for(i = 0 ; i < rl.rlim_max; i ++) {
        close(i);
    }

    // 重定向输入输出错误
    fd = open("/dev/null",O_RDWR,0);
    if(fd != -1){
        dup2(fd,STDIN_FILENO);
        dup2(fd,STDOUT_FILENO);
        dup2(fd,STDERR_FILENO);
        if (fd > 2){
            close(fd);
        }
    }
    
    // 消除文件掩码
    umask(0);
    return 0;
}

int pidfile_write(){
    // 这里不用fopen直接打开文件是不想创建666权限的文件
    FILE * pidfile = NULL;
    int pidfilefd = creat(PID_FILE,S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
    if(pidfilefd != -1){
        pidfile = fdopen(pidfilefd,"w");
    }

    if (! pidfile){
        syslog(LOG_INFO,"pidfile write : can't open pidfile:%s",PID_FILE);
        return 0;
    }
    fprintf(pidfile,"%d",getpid());
    fclose(pidfile);
    return 1;
}

int main(){
    int err,signo;
    sigset_t mask;

    if (sampled_running() > 0 ){
         exit(0);
    }

    if ( sampled() != 0 ){

    }
    // 写记录锁文件  
    if (pidfile_write() <= 0) {
        exit(0);
    }

    while(1) {
        // 捕捉信号
        err = sigwait(&mask,&signo);
        if( err != 0  ){
            syslog(LOG_INFO,"sigwait error : %d",err);
            exit(1);
        }
        switch (signo){
            default :
                syslog(LOG_INFO,"unexpected signal %d \n",signo);
                break;
            case SIGTERM:
                syslog(LOG_INFO,"got SIGTERM. exiting");
                exit(0);
        }

    }

}

程序编译运行结果，可以看到pid  、进程组id、会话id是一样的，没有终端，并且直接由pid为1的进程接管。此时的进程已经成为一个守护进程。

 

sighup与nohup

sighup（挂断）信号在控制终端或者控制进程死亡时向关联会话中的进程发出，默认进程对SIGHUP信号的处理时终止程序，所以我们在shell下建立的程序，在登录退出连接断开之后，会一并退出。

nohup，故名思议就是忽略SIGHUP信号，一般搭配& 一起使用，&表示将此程序提交为后台作业或者说后台进程组。执行下面的命令

nohup bash -c "tail -f /var/log/messages | grep sys" &

nohup与&启动的程序， 在终端还未关闭时，完全不像传统的守护进程，因为其不是会话首进程且持有终端，只是其忽略了SIGHUP信号

从nohup源码就可以看到，其实nohup只做了3件事情

1. dofile函数将输出重定向到nohup.out文件
2. signal函数设置SIGHUP信号处理函数为SIG_IGN宏（指向sigignore函数），以此忽略SIG_HUP信号
3. execvp函数用新的程序替换当前进程的代码段、数据段、堆段和栈段。

execvp 函数执行后，新程序（并没有fork进程）会继承一些调用进程属性，比如：进程id、会话id，控制终端等

登录连接断开之后

在终端关闭后，nohup起到类似守护进程的效果，但是跟传统的守护进程还是有区别的

1、nohup创建的进程工作目录是你执行命令时所在的目录

2、0 1 2 标准输入 标准输出 标准错误  指向nohup.out文件

3、nohup创建的进程组中，除首长进程的父进程id变为1之外，其余进程依然保留原来的会话id、进程组id、父进程id，都保持不变