Linux下能不能替换运行中的程序

问题到这里已经水落石出，不过刨根究底的个性驱使我再做了以下一组实验，没想到结果完全出乎我意料之外！

写了一个简单的测试程序：

#include

int main(int argc, char * argv[])
{
foo(); // An export function by libtest.so.
sleep(1000);

是另一个测试动态库libtest.so的导出接口，只打印一行提示就返回。接下来我把上面对执行文件的测试用例对动态库又做了一遍：

（1）cp libtest2.so libtest.so可以直接覆盖已加载的动态库。

（2）先rm删除已加载的libtest.so，然后cp libtest2.so libtest.so成功。

（3）先mv改名已加载的libtest.so，然后cp libtest2.so libtest.so成功。

除了第一个用例外，结果相同。这样看来，动态库被加载时难道ld并没有锁定inode？不过想想也可以宽恕，毕竟ld也是用户态程序，没有权利去锁定inode，也不应与内核的文件系统底层实现耦合。

到这里都还算在情理之中，看起来Linux也都处理的很好。不过还剩下一个问题：动态库被以cp的方式覆盖后难道不会和Demand Paging机制产生冲突？

在思考这个问题的过程中，我意识到前面这个测试程序的一个致命漏洞，稍作修改如下：

#include

int main(int argc, char * argv[])
{
loop:
foo(); // An export function by libtest.so.
sleep(1);
goto loop;
return 0;
}

这次，再执行上面的三个用例后发现，“cp libtest2.so libtest.so”虽然仍可直接覆盖已加载的动态库，但是测试程序马上出现了“Segmentation fault”。而后两个用例结果不变。由此可见，想要安全的替换已加载的动态库，还是用“笨拙”的“rm + cp”吧，看似捷径的“cp覆盖”会直接葬送掉你的程序。

看来，我再一次低估了Linux的健壮性，看似符合逻辑的流程也可能会带来灾难性的后果；“rm & cp”与“cp覆盖”背后所隐藏的底层差异却可以成为你的救星。Linux用得越久越是让人觉得这是一块充满了荆棘和陷阱的原始丛林，只有步步为营实踏前行才能走的更远。

注：以上实验基于SuSE Linux Enterprise Server 9 SP1（Linux 2.6.5 & glibc 2.3.3）。

来源:http://blog.oasisfeng.com/2008/04/14/replace-running-program-in-linux/