python中的os.fock()使用以及守护进程fork两次的原因

看socket编程顺便看python守护进程，一个网上都照抄，啥也看不明白，试验下就才看懂

简单测试fork函数

#! /usr/bin/python

import os,sys,time

print "loli"

print os.getpid()

pid = os.fork()

print "lolita"

if pid != 0:

#    print "old pid",os.getpid()

    sys.exit(0)

#    os._exit(0)

print os.getpid()

执行后出

loli

13138

lolita

13139

lolita

结果很明了了，父进程走完 os.fork()，if pid !=0就退出了，于是打印了loli ，自己 pid和lolita

子进程从fork后开始，所以没有打印loli，只打印了lolita和自己的pid

也就是说fork后自进程只执行fork后面的内容，为了子进程能挂到1下，父进程就自杀（_os.exit(0)）了

实际中需要2次fork，原因如下

http://lht709.blog.hexun.com/51126337_d.html

POSIX标准中，setsid（）系统调用，将进程与当前的会话过程和进程组分开。但是，这一作用，需要执行进程本身不是会话过程的领头进程。因此，可以通过在第一次fork（）系统调用（父进程退出）后，在子进程中执行setsid（）系统调用。来脱离进程组。

  这样，新的子进程成了新的会话过程的领头进程，也没有控制终端；但是，当它这种领头进程去打开未成为某个会话过程的控制终端的终端设备时，这类终端设备会自动成为这个没有控制终端的会话过程的控制终端。从而，背离了守护进程没有控制终端的要求。因此，需要第二次fork（）系统调用（父进程退出）后，在子进程中去完成余下工作。

简单来说你第一次fork exit后，子进程会挂在你当前启动程序的shell上，这样只有你shell退出后程序才能挂在1上，如果直接fork exit二次就能直接挂在1上

至于sys.exit(0)和os._exit(0)

os._exit()类似于sys.exit()，但它不执行任何的清除工作(例如刷新缓冲区)。所以os._exit()尤其适用于退出子进程。如果程序使用sys.exit()，操作系统会回收父进程或其它子进程可能仍然需要的资源。传给os._exit()函数的参数必须是进程的退出状态。退出状态为0，表示正常终止。

sys.exit()实际上是先执行刷新缓冲区，然后再调用os._exit

可以参考c语言的相关

1.1.3 为何在一个fork的子进程分支中使用_exit函数而不使用exit函数？
-----------------------------------------------------------------

‘exit()’与‘_exit()’有不少区别在使用‘fork()’，特别是‘vfork()’时变得很
突出。

‘exit()’与‘_exit()’的基本区别在于前一个调用实施与调用库里用户状态结构
(user-mode constructs)有关的清除工作(clean-up)，而且调用用户自定义的清除程序
(译者注：自定义清除程序由atexit函数定义，可定义多次，并以倒序执行)，相对
应，后一个函数只为进程实施内核清除工作。

在由‘fork()’创建的子进程分支里，正常情况下使用‘exit()’是不正确的，这是
因为使用它会导致标准输入输出(译者注：stdio: Standard Input Output)的缓冲区被
清空两次，而且临时文件被出乎意料的删除(译者注：临时文件由tmpfile函数创建
在系统临时目录下，文件名由系统随机生成)。在C++程序中情况会更糟，因为静
态目标(static objects)的析构函数(destructors)可以被错误地执行。(还有一些特殊情
况，比如守护程序，它们的*父进程*需要调用‘_exit()’而不是子进程；适用于绝
大多数情况的基本规则是，‘exit()’在每一次进入‘main’函数后只调用一次。)

在由‘vfork()’创建的子进程分支里，‘exit()’的使用将更加危险，因为它将影响
*父*进程的状态

摘自：

下面这个链接详细描述了python里用os.exit而不是os._exit可能造成的后果

http://technica.blogbus.com/logs/29781021.html