Linux_守护进程

内容

本节将说明守护进程结构,以及如何编写守护进程程序。因为守护进程没有控制终端,我们需要了解在出现问题时,守护进程如何报告出错情况。

  1. 守护进程的特点
  2. 进程组、控制终端、会话
  3. 守护进程编程流程

守护进程

守护进程(daemon)是生存期长的一种进程。常常在系统引导装入时启动,仅在系统关闭时才终止。因为它们没有控制终端,所以说它们是在后台运行的。UNIX系统有很多守护进程,它们执行日常事务活动。

在基于BSD的系统下执行ps -axj

选项-a显示由其他用户所拥有的进程的状态,-x显示没有控制终端的进程状态,-j显示与作业有关的信息:会话ID、进程组ID、控制终端以及终端进程组ID。

类似的命令,在基于System V的系统中,与此相类似的命令是ps -efj(为了提高安全性,某些UNIX系统不允许用户使用ps命令查看不属于自己的进程)。

有以下比较关键的列:UID(用户ID)、PID(进程ID)、PPID(父进程ID)、PGID(进程组ID)、SID(session ID, 会话ID)、终端名称(TTY)、命令字符串(CMD)。

ps命令在支持会话ID的系统上运行(Linux 3.2.0),setsid函数中的sid即会话ID。简单地说,它就是会话首进程的进程ID。

系统进程历程

系统进程依赖于操作系统实现。父进程ID为0的各进程通常是内核进程,它们作为系统引导装入过程的一部分而启动。(init是个例外,它是一个由内核在引导装入时启动的用户层次的命令。)内核进程是特殊的,通常存在于系统的整个生命期中。它们以超级用户特权运行,无控制终端,无命令行。

ps的输出实例中,内核守护进程的名字出现在方括号中,如[sshd]该版本的Linux使用一个名为kthreadd的特殊内核进程来创建其他内核进程,所以kthreadd表现为其他内核进程的父进程。对于需要在进程上下文执行工作但却不被用户层进程上下文调用的每一个内核组件,通常有它自己的内核守护进程。例如,在Linux中:

  1. kswapd守护进程,内存换页守护进程。它支持虚拟内存子系统在经过一段时间后将脏页面慢慢地写回磁盘来回收这些页面。
  2. flush守护进程在可用内存达到设置的最小阈值时将脏页面冲洗至磁盘。它也定期地将脏页面冲洗回磁盘来减少在系统出现故障时发生的数据丢失。多个冲洗守护进程可以同时存在,每个写回的设备都有一个冲洗守护进程。比如一个名为flush-8:0的冲洗守护进程。从名字中可以看出,写回设备是通过主设备号(8)和副设备号(0)来识别的。
  3. sync_supers守护进程定期将文件系统元数据冲洗至磁盘。
  4. jbd守护进程帮助实现了ext4文件系统中的日志功能。

进程1通常是init,它是一个系统守护进程,除了其他工作外,主要负责启动各运行层次特定的系统服务。这些服务通常是在它们自己拥有的守护进程的帮助下实现的。

netd守护进程。它侦听系统网络接口,以便取得来自网络的对各种网络服务进程的请求。nfsdnfsiodlockdrpciodrpe.idmapdrpc.statdrpc.mountd守护进程提供对网络文件系统(Network File System,NFS)的支持。注意,前4个是内核守护进程,后3个是用户级守护进程。

注意,大多数守护进程都以超级用户(root)特权运行。所有的守护进程都没有控制终端,其终端名设置为问号内核守护进程以无控制终端方式启动。用户层守护进程缺少控制终端可能是守护进程调用了setsid的结果。大多数用户层守护进程都是进程组的组长进程以及会话的首进程,而且是这些进程组和会话中的唯一进程rsyslogd是一个例外)。最后,应当引起注意的是用户层守护进程的父进程是init进程。

特点

运行周期长,在后台执行,不需要和用户交互。

概念

  1. 会话:每当打开一个终端,就相当于和内核建立了一个会话。再打开一个终端就会创建一个新会话,与第一个会话不同。即会话是伴随终端的打开而建立的。用会话首进程的pid来作为整个会话的sid。即使该进程结束了,会话id依然不变。
  2. 会话首进程:在该会话中运行的第一个进程。一般来讲会话首进程就是bash。
  3. 进程组:在会话中每运行一个命令,比如执行ls,会创建一个进程组,同时会创建一个进程。用该进程组的首进程pid作为整个进程组的pgid,即组长进程。进程组中有可能会有多个进程,是组内进程fork产生的。如果父进程(组长进程)结束了,pgid不会改变。只有进程组中一个进程都没有时该进程组才消失。进程组可以便于系统进行管理,比如给组长进程发一个信号,其他人都可以收到。
  4. 组长进程

如果关闭终端,则会话里的进程会全部结束。

我们要想办法使会话中的进程与终端断绝关系,独立起来。

思路:可以新建另一个会话,把终端中的进程组挪出来到这个会话里,然后就可以放心地关闭终端了。这就叫做守护进程。

创建新会话可调用setsid。但是是有条件的,调用该函数的进程不能是一个组长进程,因为这会引起组长id冲突。即必须是非组长才可创建新会话。

编程流程

  1. fork():父进程创建子进程,退出父进程,这样就保证了子进程不是组长id。
  2. setsid()
  3. fork():子进程再创建孙子进程,保证孙子进程不是组长id,保证不和终端再关联。但不必要。
  4. chdir("/"):把工作目录改变到根目录,保险,为长时间的运行做好准备。但不一定能用的到。这么做是防止被卸载。
  5. unmask():清空掩码,保证创建文件时创建出应有的权限。
  6. close():关闭用不到的文件描述符,如0、1、2
  7. 如果可能产生子进程,还需要注意处理僵死进程。

在编写守护进程程序时需遵循一些基本规则,以防止产生不必要的交互作用。 下面先说明这些规则,然后给出一个按照这些规则编写的函数daemonize

  1. 首先要做的是调用umask将文件模式创建屏蔽字设置为一个已知值(通常是0)。由继承得来的文件模式创建屏蔽字可能会被设置为拒绝某些权限。如果守护进程要创建文件,那么它可能要设置特定的权限。例如,若守护进程要创建组可读、组可写的文件,继承的文件模式创建屏蔽字可能会屏蔽上述两种权限中的一种,而使其无法发挥作用。另一方面,如果守护进程调用的库函数创建了文件,那么将文件模式创建屏蔽字设置为一个限制性更强的值(如007)可能会更明智,因为库函数可能不允许调用者通过一个显式的函数参数来设置权限。

  2. 调用fork,然后使父进程exit。这样做实现了下面几点。第一,如果该守护进程是作为一条简单的shell命令启动的,那么父进程终止会让shell认为这条命令已经执行完毕。第二,虽然子进程继承了父进程的进程组ID,但获得了一个新的进程ID,这就保证了子进程不是一个进程组的组长进程。这是下面将要进行的setsid调用的先决条件。

  3. 调用setsid创建一个新会话。然后执行9.5节中列出的3个步骤,使调用进程∶(a)成为新会话的首进程,(b)成为一个新进程组的组长进程,(c)没有控制终端。

    在基于System V的系统中,有些人建议在此时再次调用fork,终止父进程,继续使用子进程中的守护进程。这就保证了该守护进程不是会话首进程,于是按照System V规则(见UNIX环境高级编程9.6节)可以防止它取得控制终端。为了避免取得控制终端的另一种方法是,无论何时打开一个终端设备,都一定要指定O_NOCTTY

  4. 将当前工作目录更改为根日录。从父进程处继承过来的当前工作目录可能在一个挂载的文件系统中。因为守护进程通常在系统再引导之前是一直存在的,所以如果守护进程的当前工作目录在一个挂载文件系统中,那么该文件系统就不能被卸载。或者,某些守护进程还可能会把当前工作目录更改到某个指定位置,并在此位置进行它们的全部工作。例如,行式打印机假脱机守护进程就可能将其工作目录更改到它们的spool目录上。

  5. 关闭不再需要的文件描述符。这使守护进程不再持有从其父进程继承来的任何文件描述符(父进程可能是shell进程,或某个其他进程)。可以使用open_max函数(见2.17节)或getrlimit函数(见 7.11节)来判定最高文件描述符值,并关闭直到该值的所有描述符。

  6. 某些守护进程打开/dev/null使其具有文件描述符0、1和2,这样,任何一个试图读标准输入、写标准输出或标准错误的库例程都不会产生任何效果。因为守护进程并不与终端设备相关联,所以其输出无处显示,也无处从交互式用户那里接收输入。即使守护讲程是从交互式会话启动的,但是守护进程是在后台运行的,所以登录会话的终止并不影响守护进程。如果其他用户在同一终端设备上登录,我们不希望在该终端上见到守护进程的输出,用户也不期望他们在终端上的输入被守护进程读取。

实例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#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;

/* Clear file creation mask. */
umask(0);

/* Get maximum number of file descriptions. */
if(getrlimit(RLIMIT_NOFILE, &rl) < 0)
{
err_quit("%s: can't get file limit", cmd);
}
/* Become a session leader to lose controlling TTY. */
if((pid = fork()) < 0)
{
err_quit("%s: can't fork", cmd);
}
else if(pid != 0)//parent
{
exit(0);
}
setsid();
/* Ensure future opens won't allocate controlling TTYs. */
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)//parent
{
exit(0);
}
/* change the current working directory to the root,
so we won't prevent file systems from being unmounted. */
if(chdir("/") < 0)
{
err_quit("%s: can't change directory to /", cmd);
}
/* close all open file descriptors */
if(rl.rlim_max == RLIM_INFINTY)
{
rl.rlim_max = 1024;
}
for(i = 0; i < rl.rlim_max; ++i)
{
close(i);
}
/* attach file descriptors 0, 1, and 2 to /dev/null */
fd0 = open("/dev/null", O_RDWR);
fd1 = dup(0);
fd2 = dup(0);
/* initialize the log file. */
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);
}
}

daemonize函数由main程序调用,然后main程序进入休眠状态,那么可以用ps命令检查该守护进程的状态:

1
2
3
4
5
6
$ ./a.out
$ ps -efj
UID PID PPID PGID SID TTY CMD
sar 13800 1 13799 13799 ? ./a.out
$ ps -efj | grep 13799
sar 13800 1 13799 13799 ? ./a.out

我们也可用ps命令验证,没有活动进程存在的ID是13799。这意味着,守护进程在一个孤儿进程组中(见9.10节),它不是会话首进程,因此没有机会被分配到一个控制终端。这一结果是在daemonize函数中执行第二个fork造成的。可以看出,守护进程已经被正确地初始化了。