昨天BSC测试组开了一个U0的Fault Report.
后来发现问题了:正常情况下当我们的CCP板插入机架后,本来OMCP板应该先配置其dhcp,然后restart dhcp,这样CCP板才能正常工作。但是现在看到的情况是,在dhcp配置完成之前,OMCP上的dhcp server就被restart了。细读trace和代码,最终发现了问题所在---->System函数调用后台执行的脚本。
先介绍一下System函数,在linux中man system得到的解释是:
system() executes a command specified in string by calling /bin/sh -c string, and returns after the command has been completed. During execution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.
system() 以字符串为参数,该字符串是一个shell命令或者shell脚本。shell命令或脚本返回后,system()才返回,在此过程中SIGCHLD会被阻塞,SIGINT和SIGQUIT会被忽略。
再回到前面我说的问题,在我的程序中:
int rc;
rc = system(/usr/local/bin/build_dhcp.sh &"); // (1)
......
rc = system("/etc/init.d/dhcpd restart"); // (2)
rc = system(/usr/local/bin/build_dhcp.sh &"); // (1)
......
rc = system("/etc/init.d/dhcpd restart"); // (2)
根据man system得到的信息,从字面上看,容易让人(比如我T_T)产生误会,以为(1)处的脚本完全执行完,dhcp配置好了,(1)处的system函数才会返回,接下来再执行(2)处的命令来restart dhcp。事实上,并非如此,(1)处的system函数调用shell脚本,该脚本转为后台执行,此时system函数就返回了,接下来(2)的system函数就开始执行了。由于build_dhcp.sh执行时间较长,因此,当dhcp还没有配置好的时候,dhcp server restart,最终导致插进去的这个CCP板无法正常工作。
工作的问题解决了,大快人心。顺便也就进一步了解一下system函数吧。
Linux中system()源码如下:
解释一下,当命令参数为NULL时直接返回,否则fork出一个子进程。
顺便说一下fork(),假如在进程A调用fork(),内核就创建一个新的进程B,并将A的内存映像复制到B的进程空间中。因此,进程A和进程B一模一样,只有根据fork()的返回值就才能知道谁是父进程,谁是子进程。fork在子进程中返回0,在父进程中返回子进程的pid。
在system()的源代码中,父进程使用waitpid等待子进程结束,子进程则是通过调用execl("/bin/sh", "sh", "-c", cmdstring, (char*)0)调用shell,这个shell的路径是/bin/sh,然后子进程就变成了一个shell进程,这个shell的参数就是system接受的参数,在windows中的shell是command。





































