最近一段时间，公司的网管系统二期优化需要新增功能，实现对网管客户端程序进行保护的监控脚本的自动更新及保护进程的监控告警。网管客户端程序分为两部分：客户端GatherClient及保护进程gatherclient_daemon.py，其中保护脚本由Python编写，主要功能是实现客户端进程崩溃或意外被杀死后的自动恢复。目前网管系统支持Windows和Linux平台。下面主要讲述在Linux下实现遇到的问题。
为了实现上述的两功能，需要解决以下两方面问题：
1、获取保护脚本进程是否存在。
对Python脚本保护进程的实时监控 ，需要获取当前系统的进程信息，以判定该进程是否存活。由于py脚本均是由Python二进制模块以参数的形式加载并产生进程 ，而在系统中的进程名均为python，这样若系统存在其他py脚本在运行，则无法区分，不过这个问题可能通过获取进程的参数信息来区分所对应的py脚本(Windows和Linux均可获取进程参数信息)，此处不细述。
2、py脚本的自动更新及加载。
当网管系统服务端有脚本gatherclient_daemon.py的更新时，需要客户端程序能够自动下载脚本，并完成对更新后的py脚本的加载启动。而我们的客户端由于公司各游戏业务的服务器物理上分布很分散，均为远程操作，当客户端程序有版本更新时，会自动下载新程序文件，然后客户端自动退出，由保护进程gatherclient_daemon.py负责启动更新后的客户端进程，因此优先更新py文件并保证正常重新启动对GatherClient的自动更新功能显得尤为关键。
Linux下启动一个新进程的方法有：调用fork( )，system( )以启动子进程的方式实现，其中system( )的系统内部实现也是调用fork( )及Waitpid等。这里就涉及到Linux下的父子进程产生及资源的继承关系的问题。
关于fork( )产生子进程的理解，可看下面一段示例及解析：
要搞清楚fork的执行过程，就必须先讲清楚操作系统中的“进程(process)”概念。一个进程，主要包含三个元素：
一个可以执行的程序；
和该进程相关联的全部数据（包括变量，内存空间，缓冲区等等）；
程序的执行上下文（execution context）。
不妨简单理解为，一个进程表示的，就是一个可执行程序的一次执行过程中的一个状态。操作系统对进程的管理，典型的情况，是通过进程表完成的。进程表中的每一个表项，记录的是当前操作系统中一个进程的情况。对于单 CPU的情况而言，每一特定时刻只有一个进程占用 CPU，但是系统中可能同时存在多个活动的（等待执行或继续执行的）进程。
一个称为“程序计数器（program counter, pc）”的寄存器，指出当前占用 CPU的进程要执行的下一条指令的位置。
当分给某个进程的 CPU时间已经用完，操作系统将该进程相关的寄存器的值，保存到该进程在进程表中对应的表项里面；把将要接替这个进程占用 CPU的那个进程的上下文，从进程表中读出，并更新相应的寄存器（这个过程称为“上下文交换(process context switch)”，实际的上下文交换需要涉及到更多的数据，那和fork无关，不再多说，主要要记住程序寄存器pc指出程序当前已经执行到哪里，是进程上下文的重要内容，换出 CPU的进程要保存这个寄存器的值，换入CPU的进程，也要根据进程表中保存的本进程执行上下文信息，更新这个寄存器）。
好了，有这些概念打底，可以说fork了。当你的程序执行到下面的语句：
pid=fork();
操作系统创建一个新的进程（子进程），并且在进程表中相应为它建立一个新的表项。新进程和原有进程的可执行程序是同一个程序；上下文和数据，绝大部分就是原进程（父进程）的拷贝，但它们是两个相互独立的进程！此时程序寄存器pc，在父、子进程的上下文中都声称，这个进程目前执行到fork调用即将返回（此时子进程不占有CPU，子进程的pc不是真正保存在寄存器中，而是作为进程上下文保存在进程表中的对应表项内）。问题是怎么返回，在父子进程中就分道扬镳。
父进程继续执行，操作系统对fork的实现，使这个调用在父进程中返回刚刚创建的子进程的pid（一个正整数），所以下面的if语句中pid<0, pid==0的两个分支都不会执行。所以输出i am the parent process...
子进程在之后的某个时候得到调度，它的上下文被换入，占据 CPU，操作系统对fork的实现，使得子进程中fork调用返回0。所以在这个进程（注意这不是父进程了哦，虽然是同一个程序，但是这是同一个程序的另外一次执行，在操作系统中这次执行是由另外一个进程表示的，从执行的角度说和父进程相互独立）中pid=0。这个进程继续执行的过程中，if语句中pid<0不满足，但是pid==0是true。所以输出i am the child process...
我想你比较困惑的就是，为什么看上去程序中互斥的两个分支都被执行了。在一个程序的一次执行中，这当然是不可能的；但是你看到的两行输出是来自两个进程，这两个进程来自同一个程序的两次执行。
在以system( )启动py脚本的实现过程中，遇到了两个问题：
（1）调用system启动py脚本创建保护子进程时，Python报下列错误：
[root@otctest bin]$ Traceback (most recent call last):
File "gatherclient_daemon.py", line 295, in ?
main(sys.argv)
File "gatherclient_daemon.py", line 273, in main
Run()
File "gatherclient_daemon.py", line 243, in Run
daemon = Daemon()
File "gatherclient_daemon.py", line 30, in __init__
self.system = platform.system()
File "/usr/lib/python2.4/platform.py", line 1035, in system
return uname()[0]
File "/usr/lib/python2.4/platform.py", line 1007, in uname
processor = _syscmd_uname('-p','')
File "/usr/lib/python2.4/platform.py", line 794, in _syscmd_uname
rc = f.close()
IOError: [Errno 10] No child processes
可以发现原因是找不到子进程。排查gatherclient C程序，发现原来是因为我这个python程序本身是由gatherclient C程序调用的，gatherclient及py脚本均是以守护进程的模式在后台运行，而调用它的gatherclient程序中将SIGCLD信号忽略了（这表明system( )是根据子进程退出时产生的信号来获取返回值的），所以主进程gatherclient将不再接收子进程的返回值。为了解决这个问题且不造成子进程变成僵尸进程，修改代码：
signal(SIGCHLD,SIG_DFL); //默认处理方式，是接收子进程的返回值。
从下面的源码分析可看出 system( )的实现：
int system(const char * cmdstring)
{
pid_t pid;
int status;
if(cmdstring == NULL)
{
return (1);
}
if((pid = fork())<0)
{
status = -1;
}
else if(pid == 0)
{
execl("/bin/sh", "sh", "-c", cmdstring, (char *)0);
_exit(127);
}
else
{
while(waitpid(pid, &status, 0) < 0)
{
if(errno != EINTR)
{
status = -1;
break;
}
}
}
return status;
}
2.6内核下当父进程未调用wait系列函数等待子进程结束且未显式地忽略SIGCHLD信号，则子进程将成为僵死进程（如果显示忽略，则子进程不僵死）；因而在SIGCHLD信号被显式忽略的情况下，2.6内核子进程将直接退出并释放资源，等父进程调用waitpid时,发现对应的pid进程已不存在，因而返回-1错误，errno为10（No child processes）；
（2）py脚本及gatherclient文件更新后（gatherclient自动退出），py脚本自动拉起gatherclient程序时，父进程gatherclient拥有的资源在子进程退出前未释放的问题。
分析后发现是由于gatherclient中的一处文件锁未释放导致。gatherclient实现时，保证客户端正常地收集系统运行状态信息及告警，要确保在系统中只有一个客户端进程存在，程序初始化时创建了一个排他性的进程锁（文件锁），而py脚本是gatherclient进程中以system调用产生子进程的方式启动，即py子进程继承了父进程gatherclient的所有资源，包括文件锁，socket套接字资源等。根据上面的fork的理解：
新进程和原有进程的可执行程序是同一个程序；上下文和数据，绝大部分就是原进程（父进程）的拷贝，但它们是两个相互独立的进程！
父进程gatherclient退出时，它所持有的文件锁和socket资源自动释放，但问题在于父进程和子进程是两个独立的进程，py子进程并未退出，会一直持有先前父进程打开的文件锁和socket资源。这样当py脚本启动gatherclient时，就会出现文件锁已打开，无法启动的问题。解决办法是自己重写system（），在其中调用fork( )之后产生的子进程中关闭父进程打开的文件锁，socket套接字以释放资源。（实际调试测试表明，子进程未退出前，先前打开的socket套接字不会关闭且有效，程序中因此出现了socket超时才被关闭的情况）
在Linux下进行多进程程序的开发，要十分注意父子进程的资源的继承关系。