将一个进程转变为守护进程所需要的步骤

       如果想要把一个普通进程转变为守护进程。我们需要在此进程中进行下面一些步骤：(根据Unix网络编程卷一P289-291总结而来)

1．fork
   首先调用fork ，然后使父进程exit。这样做实现了以下几点：如果该守护进程是作为一条简单的shell 命令在命令行上前台启动的，那么父进程终止会让shell 认为这条命令已经执行完毕，这样子进程就自动成为后台进程。第二，虽然子进程从父进程那里继承了进程组ID，但获得了一个新的进程ID，这就保证了子进程不会是一个进程组的组长进程。这一点是下一步进行setsid调用的先决条件(调用setsid时如果调用进程已经是一个进程组的组长，则此函数返回出错)。
2．setsid
    调用setsid创建一个新会话。这使调用进程：a) 成为新会话的首进程，b) 成为一个新进程组的组长进程，c) 没有控制终端，成为了独立于终端外的进程。
3．忽略SIGHUP 信号，重新fork
    fork的目的是使进程不再是进程组的首进程，可以防止在某些情况下进程意外的打开终端而重新与终端发生联系。当没有控制终端的一个会话头进程打开一个终端设备时(该终端不是当前其他会话的控制终端)，该终端自动成为这个会话首进程的控制终端。然而再次调用fork之后，我们确保新的子进程不再是一个会话首进程，从而不能自动获得一个控制终端。这里必须忽略SIGHUP信号，因为当会话头进程(即首次fork产生的子进程)终止时，其会话中的所有进程(即再次fork产生的子进程)都会收到SIGHUP信号。

4. 为错误处理函数设置标识

     设置错误输出，利用syslog函数，向syslogd发送消息。将错误输出到日志文件。

5．改变工作目录，清除文件掩码
     改变工作目录主要是为了切断进程与原有文件系统的联系。并且保证无论从什么地方启动进程都能正常的工作。清除文件掩码是为了消除进程自身掩码对其创建文件的影响。
6．关闭全部已打开的文件句柄，和描述符
     这是为了防止子进程继承了在父进程中打开的文件而使这些文件始终保持打开从而产生某些冲突。

7. 将stdin,stdout,stderr重定向到/dev/null

     打开/dev/null作为本守护进程的标准输入，标准输出和标准错误输出。这一点保证这些常用描述符是打开的。针对它们的read系统调用返回0(EOF)，write系统调用则由内核丢弃所写数据。打开这些描述符的理由在于，守护进程调用的那些假设能从标准输入读或者往标准输出或标准错误输出写的库函数将不会因这些描述符未打开而失败。这种失败是一种隐患。要是一个守护进程未打开这些描述符，却作为服务器打开了与某个客户关联的一个套接字，那么这个套接字很可能占用这些描述符(譬如标准输出或标准错误输出的描述符1或2)，这种情况下如果守护进程调用诸如perror之类函数，那么就会把非预期的数据发送给那个客户。

单实例守护进程

        文件和记录锁机制为一种方法提供了基础，该方法保证一个守护进程只有一个副本在运行。如果每一个守护进程创建一个有固定名字的文件，并在该文件的整体上加一把写锁，那么只允许创建一把这样的写锁。在此之后创建写锁的尝试都会失败，这向后续守护进程副本指明已有一个副本正在运行。文件和记录锁提供了一种方便的互斥机制。如果守护进程在一个文件的整体上得到了一把写锁，那么在该守护进程终止时，这把锁将被自动删除。

守护进程的惯例

• 若守护进程使用锁文件，那么该文件通常存储在/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就将重新启动该守护进程。(假定系统使用System V风格的init命令。)
  

• 若一个守护进程有一个配置文件，那么当该守护进程启动时会读该文件，但在此之后一般就不会再查看它。若某个管理员更改了配置文件，那么该守护进程可能需要被停止，然后再启动，以使配置文件的更改生效。为避免此种麻烦，某些守护进程将捕捉SIGHUP信号，当它们接收到该信号时，重新读配置文件。因为守护进程并不与终端相结合，它们或者是无控制终端的会话首进程，或者是孤儿进程组的成员，所以守护进程没有理由期望接收SIGHUP。于是，守护进程可以安全地重复使用SIGHUP。