在Linux运维中经常遇到要替换Linux服务器系统程序或者业务应用程序文件的情况，很多人都会担心，直接替换会不会导致Linux系统程序崩溃或者应用程序崩溃，而需要关闭服务才敢替换，今天在freebuf网站偶然阅读到一篇文章《如何进行Linux平台共享库替换》，突然明白了以前没有搞清楚的几个自认为“奇怪”的现象。
这些现象包括但不限于：
- 删除某个应用程序的部分文件，为何不会导致此应用程序崩溃
- nginx等服务如何可以做到平滑重启
- 某些删除的文件为何可以通过lsof根据inode找回
- 为何某些应用程序的文件替换或变更后需要重启才能生效
问题的答案在这篇文章中得到了很清楚的解答。原来（下面文字为直接引用），
针对未被加载的SO，利用复制命令（cp new.so old.so）即可直接完成静态替换，新SO在下次加载时生效。对于已经加载的原SO，直接用新SO复制替换将会导致相应程序崩溃，此种情况可以使用删除原SO（rm -f old.so）或修改原SO名称（mv old.so oldx.so）后，再复制新SO的方法代替，新SO同样在下次加载时生效。
程序崩溃的原因是复制替换操作会破坏系统访问原SO的索引节点inode，导致系统找不到原SO。系统为每个加载到内存中的文件创建对应的inode，用来管理该文件，inode包含了文件的元信息，如文件字节数、拥有者ID、读写执行权限等。系统以inode标识程 序加载的SO，不再关心文件名，修改SO名称并未改变对应inode，因此程序可以继续正常运行；删除SO只是无法查看，系统直到程序释放SO后才真正删除SO和inode，因此程序也可以继续正常运行；但是在直接复制替换时，新SO将会继承原SO的inode，程序无法继续访问原SO，从而导致程序崩溃。
因此，按照这个思路，日后在Linux运维工作中，可以按照这个理论去做一些事情，比如无论是在修改还是替换钱都保留源文件，这也是为什么在做修改前要备份的理由之一。
参考文章：如何进行Linux平台共享库替换
tag:生产环境,文件删除,文件替换,如何上线,操作标准
--end--