[单刷APUE系列]第十三章——守护进程

浏览: 97 发布日期: 2016-08-17 分类: unix

守护进程

守护进程对于Unix运维来说应该是不陌生的,所有的提供服务的进程基本上都是守护进程,通常也可以称为服务。它们由init进程启动,并且没有控制终端,是一种执行日常事务的进程。
在Unix系统下,有很多守护进程,在基于BSD的系统下运行下列命令

ps -axj

-a选项显示所有进程,包括其他用户的进程,-x显示没有控制终端的进程状态,-j显示与作业有关的信息:会话ID、进程组ID、控制终端以及终端进程组ID。在基于SystemV的系统中,对应命令是ps -efj,具体如何需要查看自己的ps命令说明,当然还有一些系统只允许超级用户查看到其他的用户进程,普通用户不能查看其他用户进程。
我们知道,除了用户进程以外,还有很多系统进程,比如守护进程,对于大部分Unix环境来说,使用的都是SystemV风格的init启动方式,首先是Grub引导内核启动,然后内核会查找/sbin/init程序并且启动它,init程序会根据一系列的配置文件启动不同的脚本,最终启动守护进程。当然,目前最新的操作系统基本上都是systemd,所以是不同的,但是基本原理还是相同的,比如同样都是root权限运行,所有守护进程没有控制终端,

编程规则

编写守护进程的时候需要遵循一些规则,以免出现各种问题

  1. 首先是调用umask函数设置文件屏蔽字,比如0,因为守护进程是fork产生的,继承来的文件模式创建屏蔽字可能会被设置为拒绝某些权限

  2. 调用fork,然后使父进程exit。首先,由于我们不知道守护进程是如何产生的,它有可能是用户shell调用后产生的,所以我们需要让其能被init托管。其次,子进程虽然继承了父进程的进程组ID,但是却有了新的进程ID,也就是说,不可能是组长进程了

  3. 调用setsid创建一个会话,使进程成为新会话的首进程,成为一个新进程组的组长进程,没有控制终端

  4. 将当前工作目录设置为/目录。因为从父进程继承过来的属性可能会导致文件系统无法卸载,所以我们需要使用chdir()函数。

  5. 关闭不需要的文件描述符

  6. 某些守护进程在0、1、2上打开/dev/null来保证不会有标准输入输出。

#include "include/apue.h"
#include <syslog.h>
#include <fcntl.h>
#include <sys/resource.h>

void daemonize(const char *cmd)
{
    int i, fd0, fd1, fd2;
    pid_t pid;
    struct rlimit rl;
    struct sigaction sa;
    
    umask(0);
    
    if (getrlimit(RLIMIT_NOFILE, &rl) < 0)
        err_quit("%s: can't get file limit", cmd);
        
    if ((pid = fork()) < 0)
        err_quit("%s: can't fork", cmd);
    else if (pid != 0)
        exit();
    setsid();
    
    sa.sa_handler = SIG_IGN;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    if (sigaction(SIGHUP, &sa, NULL) < 0)
        err_quit("%s: can't ignore SIGHUP", cmd);
    if ((pid = fork()) < 0)
        err_quit("%s: can't fork", cmd);
    else if (pid != 0)
        exit();
        
    if (chdir("/") < 0)
        err_quit("%s: can't change directory to /", cmd);
    
    if (rl.rlim_max == RLIM_INFINITY)
        rl.rlim_max = 1024;
    for (i = 0; i < rl.rlim_max; ++i)
        close(i);
        
    fd0 = open("/dev/null", O_RDWR);
    fd1 = dup(0);
    fd2 = dup(0);
    
    openlog(cmd, LOG_CONS, LOG_DAEMON);
    if (fd0 != 0 || fd1 != 1 || fd2 != 2) {
        syslog(LOG_ERR, "unexpected file descriptors %d %d %d", fd0, fd1, fd2);
        exit(1);
    }
}

上面这个函数实际上就是之前所说必须遵循的规则的写法,只需要通过main函数调用这个函数就能使进程变为守护进程,当然,由于权限问题,实际上并不是实际的写法。

日志

守护进程的一个问题就是日志问题,我们知道,任何的程序必然需要有方式记录下自己的活动日志,对于大部分情况来说,都是通过标准输入标准输出标准错误的形式记录日志,但是守护进程没有控制终端,不能写到标准错误上,而且我们也不会希望它写到终端上,其中一个解决方法是写到一个单独的文件中,但是这样会让运维人员非常头痛,因为程序一多就会非常混乱,所以就需要一个集中式的守护进程来记录日志。
syslog是BSD伯克利开发的,广泛运用于BSD系列的系统中,后来成为了Unix标准之一。当然,目前由于systemd的实质性接管,所以syslog的作用正在被systemd蚕食,这里不是讨论的重点。
syslog的架构很简单,但是很有效,syslogd作为系统服务启动,然后侦听/dev/logsocket、/dev/klogsocket和UDP514端口。其中/dev/log用于接收本地用户进程的日志信息,UDP514端口接收网络上的日志信息,/dev/klog则是监听内核的日志信息。
由于这种架构,所以开发者可以使用三种方法产生日志信息

  1. 内核例程可以调用log函数,任何一个用户进程都可以打开读取/dev/klog读取信息

  2. 守护进程调用syslog函数来产生日志信息,最终这些信息将被发送到/dev/log

  3. 任何进程都可以向UDP514端口发送日志信息。

syslogd在启动的时候回读取配置文件,一般在/etc/syslog.conf,里面决定了消息应当被发送到何处,甚至有可能重要信息会被在管理员控制台上打印。

void openlog(const char *ident, int option, int facility);
void syslog(int priority, const char *format, ...);
void closelog(void);
int setlogmask(int maskpri);

openlog函数让开发者指定一个ident参数,也就是标识符,以后,这个ident将被加到每则日志消息中。option参数则是指定了各种选项位屏蔽。

option 说明
LOG_CONS 若日志信息不能通过Unix Domain数据报,则将该消息写入控制台
LONG_NDELAY 立即打开至syslogd守护进程的Unix Domain数据报套接字,不要等到第一条信息已经被记录时候再打开。通常,在记录第一条信息之前,不打开套接字
LOG_NOWAIT 不要等待在将消息记录日志过程中可能以创建的子进程,因为在syslog调用wait时,应用程序可能已获得了子进程的状态。这种处理阻止了与捕捉SIGCHLD信号的应用程序之前产生的冲突
LOG_ODELAY 在第一条消息被记录之前延迟打开链接
LOG_PERROR 除将日志消息发送给syslogd以外,还将其写入到标准错误
LOG_PID 记录每条信息都要包含进程ID

openlog的facility参数值则包含了很多可选值,但是非常遗憾的是,只有少部分是能被跨平台使用的。具体可以参见各平台的Unix手册。
syslog函数则会产生一条日志,其priority参数是facility和level的组合,format参数则是格式化字符串,基本和vsprintf函数一样。
setlogmask函数用于设置进程的记录优先级屏蔽字。它返回调用它之前的屏蔽字,也就是可以用来存储着或者了解之前的屏蔽字状态,各条消息除非已在记录优先级屏蔽字中进行了设置,否则不会被记录。

单实例守护进程

很多情况下,守护进程只是一个进程,因为不需要并发地进行操作,而且这样很有可能导致资源竞争,所以在很多情况下,守护进程只会实现在任意时刻只存在守护进程一个副本,所以为了保证只存在一个副本,就需要一种机制来保证。而文件和记录锁就是这样一种保证方式,实际上,不单单是单实例守护进程,几乎所有的守护进程都采用了这种方式。

#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <syslog.h>
#include <string.h>
#include <errno.h>
#include <stdio.h>
#include <sys/stat.h>

#define LOCKFILE "/var/run/daemon.pid"
#define LOCKMODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH)

extern int lockfile(int);

int already_running(void)
{
    int fd;
    char buf[16];
    
    fd = open(LOCKFILE, O_RDWR | O_CREATE, LOCKMODE);
    if (fd < 0) {
        syslog(LOG_ERR, "can't open %s: %s", LOCKFILE, strerror(error));
        exit(1);
    }
    if (lockfile(fd) < 0) {
        if (errno == EACCES || errno == EAGAIN) {
            close(fd);
            return(1);
        }
        syslog(LOG_ERR, "can't lock %s: %s", LOCKFILE, strerror(errno));
        exit(1);
    }
    ftruncate(fd, 0);
    sprintf(buf, "%ld", (long)getpid());
    write(fd, buf, strlen(buf) + 1);
    return(0);
}

实际上上面的行为非常常见,守护进程启动的时候试图创建一个文件并且将进程ID写入其中,如果该文件加锁,则lockfile函数将会失败,并且返回,表明已经有守护进程正在运行。否则将文件长度截断为0,将进程ID写入其中。

守护进程的惯例

  1. 如果守护进程使用锁文件,那么该文件通常存储在/var/run目录中。不过需要注意,守护进程需要超级用户权限才能创建文件。锁文件名字一般是name.pid

  2. 如果守护进程支持配置文件,则配置文件一般存储在/etc目录中。

  3. 守护进程可以通过命令行启动,但是通常是使用init脚本启动的。

  4. 如果一个守护进程有一个配置文件,在启动的时候会读取该文件,但是在此之后一般就不会再查看它。如果管理员更改了配置文件,那么该守护进程可能需要重新启动,后来在信号机制中加入了SIGHUP信号的捕捉,让守护进程接收到信号后重新读取配置文件。

客户进程-服务器进程模型

C/S进程模型在Unix环境中非常常见,守护进程通常就是服务器进程,然后等待客户进程语气联系,提出某种类型的请求,为了保证请求的高效处理,服务器进程中调用fork然后exec另一个程序来提供服务是非常常见的。这些服务器进程通常管理着多种资源。而为了保证文件描述符不被滥用,所以需要对所有被执行程序不需要的文件描述符设置成执行时关闭(close-on-exec)。

返回顶部