APUE读书笔记(21) 守护进程

一:守护进程
  守护进程是一类生存周期较长的进程,一般在系统开启的时候产生,系统关闭的时候才销毁。守护进程在后台运行,帮助UNIX系统执行日常事务活动。
二:守护进程的特征
  通过ps命令可以查看进程列表,可以展示进程号,父进程号等信息。父进程号为0的个进程一般为内核进程。内核进程的生命周期与整个系统的生命周期一样,它以超级用户权限执行,无控制终端,无命令行。
  进程1为init进程,他是一个系统守护进程,主要负责启动各运行层次的系统服务,这些服务一般也都是在他们对应的守护进程的帮助下实现的。
  大多数的守护进程都是以root权限运行的。所有的守护进程都没有控制终端,他们的终端名设置为问号
APUE读书笔记(21) 守护进程_第1张图片
三:编程规则
  在编写守护进程时需要遵循一些基本规则,以防止产生不必要的交互。
  1.调用umask将文件模式创建屏蔽字设置为一个已知值(通常是0)。由继承的来的文件模式创建屏蔽字可能会设置为拒绝某些权限。如果守护进程要创建文件,那么他可能要设置特定的权限。
  2.调用fork,然后使父进程退出。这样做实现了下面几个点:如果该守护进程是作为一条简单的shell命令启动的,那么父进程终止会让shell认为这条命令已经执行完毕;虽然子进程继承了父进程的进程组ID,但获得了一个新的进程ID,这保证了子进程不是一个父进程的组长进程。这也是下面调用setsid的先决条件
  3.调用sedsid创建一个新会话。
  4.将当前工作目录改为根目录。
  5.关闭不再需要的文件描述符。
  6.某些守护进程会打开/dev/null。
四:出错记录
  守护进程需要解决的一个问题就是如何处理出错消息。由于守护进程不具有控制终端,所以不能只是简单的写到标准错误上。如果将不同守护进程写入到不同的日志文件中,对于一个系统管理人员来说,还需要定期去查看所有日志文件有没有出错,是非常痛苦的一件事情。所以在一个需要有一个集中地守护进程出错记录设施。
APUE读书笔记(21) 守护进程_第2张图片
  syslog就是解决这个问题的设施。有三种产生日志消息的方法:
  1.内核例程调用log函数。任何一个用户进程都可以打开并读取/dev/klog设备来读取这些消息。
  2.大多数的用户进程或者守护进程可以调用syslog(3)函数来产生日志消息。
  3.通过TCP/IP网络连接到UDP端口514。
  通常,syslogd守护进程读取所有三种格式的日志消息。此守护进程在启动时读一个配置文件,其文件名一般为/etc/syslog.conf,该配置文件决定了不同的消息应该去向何处。比如紧急消息可以直接发送给登陆的系统管理员,打印在终端上;而警告消息则可以记录到一个文件中。
APUE读书笔记(21) 守护进程_第3张图片
  这个设备的接口是syslog函数。这三个函数见名知意,就不细说了。
五:单例守护进程
  为了正常运作,某些守护进程可能会实现为:在任意时刻只运行该守护进程的一个副本。例如,这种守护进程必须排他性的使用一个设备,那么当多个多个守护进程同时使用这个设备的时候,就会出错。这个只是举一个例子,具体是哪类进程,是哪个设备不再具体的讨论范围里。
  为了保证能够实现单例的守护进程,可以用到文件和记录锁。如果每一个守护进程创建一个相同的名字的文件,并在该文件加上一把写锁,那么只允许创建一把这样的写锁。在此之后创建写锁的的尝试都会失败。
六:守护进程的惯例
  在UNIX系统中,守护进程遵循下列公共惯例:
  若守护进程使用锁文件,那么该文件通常存放在/var/run目录中。注意,守护进程可能需要具有超级用户权限才能在此目录下创建文件。锁文件的名字通常是name.pid,其中,name是该守护进程或服务的名字。例如cron守护进程锁文件的名字是/var/run/crond.pid。
  若守护进程支持配置选项,那么配置文件通常存放在/etc目录中。配置文件的名字通常是name.conf,其中,name是该守护进程或服务的名字。例如,syslogd守护进程的配置文件是/etc/syslog.conf。
  守护进程可用命令行启动,但通常它们是由系统初始化脚本之一(/etc/rc或/etc/init.d/)启动的。如果在守护进程终止时,应当自动地重新启动它,则我们可在/etc/inittab中为该守护进程包括_respawn记录项,这样,init就将重启动该守护进程。
  若一守护进程有一配置文件,那么当该守护进程启动时,它读该文件,但在此之后一般就不会再查看它。若一管理员更改了配置文件,那么该守护进程可能需要被停止,然后再启动,以使配置文件的更改生效。为避免此种麻烦,某些守护进程将捕捉SIGHUP信号,当它们接收到该信号时,重读配置文件。因为守护进程并不与终端相结合,它们或者是无控制终端的会话首进程,或者是孤儿进程组的成员,所以守护进程并不期望接收SIGHUP。于是,它们可以安全地重复使用它。

你可能感兴趣的:(APUE)