守护进程(类似Windows的服务)：通常被定义为一个后台进程，而且它不属于任何一个终端会话(terminal session)。许多系统服务由守护程序实施；如网络服务，打印等。
下面介绍下守护进程的基本编码过程以及python的对应实现：
1. 调用 fork 并使父进程退出(exit)( 若父进程退出，子进程尚未结束，则子进程会被init进程领养，也就是说init进程将成为该子进程的父进程)。这一步骤的目的在于。首先，如果守护进程是通过一个简单的shell命令建立的，那么在父进程终止的时候shell会认为命令已经结束了继而结束守护进程。其次，子进程继承得到父进程的groupID同时也获得了一个新的进程号，所以我们必须得保证子进程不能担任groupleader()的角色，这是下一步setsid 操作的前提。
注：此步骤是使得进程在后台运行
pid = os.fork()if pid > 0 sys.exit(0)
2. 调用 setsid 创建一个新的会话(当进程是会话的领头进程时setsid()调用失败并返回（-1）。setsid()调用成功后，返回新的会话的ID，调用setsid函数的进程成为新的会话的领头进程，并与其父进程的会话组和进程组脱离。由于会话对控制终端的独占性，进程同时与控制终端脱离)。有三个步骤将会执行：
- 进程将成为这个新会话的sessionleader角色
- 此进程将会成为一个新的进程组的groupleader
- 此进程将不会有控制终端。
注：此步骤将使得进程脱离控制终端、登录会话以及进程组。
os.setsid()3. 接下来要做的被称为umask（ 文件的默认权限，补码），这一步骤会将文件创建掩码重置为0（ 因为是补码，所以0为权限最大）。这一步的原因是守护进程继承(inherited)得到的文件掩码有可能会拒绝某些特定的文件操作权限。如果守护进程想要创建文件，那有可能它需要设置特定的文件操作权限。例如，如果守护进程想要创建允许组读和写(group-readand group-write)权限的文件，但继承得到的文件创建掩码屏蔽了这个权限，则创建操作不会成功。
os.umask(0)
4. 将当前的工作目录切换到系统根目录下。因为从父进程集成来的当前工作目录可能是一个被挂载的文件系统。因为守护进程通常是直到系统重启的时候才会退出，如果守护进程的工作目录在一个挂载的文件系统上，那么这个文件系统就不能被卸载(unmounted)。
有的守护进程可能会将当前的工作目录切换到一些特定的路径，在这些路径下它们将完成它们的工作。例如，lineprinter spoolingdaemons 通常将工作目录切换为spool目录。
os.chdir("/") 5. 在基于SystemV的系统中，有建议再一次调用fork 并使父进程退出。而新产生的进程将会成为真正的守护进程( 这意味着一 个非会话组头领进程永远不能重新获得控制终端 )。这一步骤将保证守护进程不是一个sessionleader，进而阻止它获取一个控制终端。或者另一种阻止守护进程获取控制终端的方案是任意时刻打开一个终端设备的时候确保指定O_NOCTTY。 注：此步骤将禁止进程重新打开控制终端。
pid = os.fork()if pid > 0 sys.exit(0)6. 一些不必要的文件描述符将会被关闭。这个步骤将阻止守护进程保持从父进程集成到的任何已经打开的文件描述符(也可能是shell或其他进程)。我们可以使用 open_max 函数或 getrlimit 函数来查找当前优先级最高的文件描述符并关闭此描述符之下的所有其他描述符。
注：保持打开的描述符将会占用系统资源并可能使某些文件不能被卸载。
7. 有一些守护进程将打开文件描述符0, 1, 2 指向 /dev/null ，这样一来所有试图从标准输入、输出及错误读取守护进程信息的操作都不能成功。因为守护进程当前已经不与任何终端设备相关联，没有地方显示其输出或接受用户的输入。即使守护进程是从一个交互式session创建的，守护进程也将运行在后台，任何终端的登录与终止将不会影响守护进程。如果有其他用户通过当前的终端登录，我们也不希望守护进程的输出出现在终端上，并且该用户的任何输入也不会被守护进程接收。
总结:
- 第一次fork将会创建父-子进程，同时使得父进程退出保证守护进程能够运行在后台。
- 通过setsid步骤使得进程与控制终端、登录会话以及进程组脱离。
- 第二次fork将确保进程重新打开控制终端，并且产生子-孙进程，而子进程退出后孙进程将成为真正的守护进程（非会话组头领），进制重新打开控制终端。
- 其他还有一些诸如工作目录设置、关闭文件描述符、设置文件创建掩码之类的操作。
参考资料：
1. http://edison0951.iteye.com/blog/610727
2. http://blog.csdn.net/dysj4099/article/details/18219411