linux替换运行程序或so动态库文件导致的问题

linux中替换运行中的程序或者so文件导致的问题

参考博文
http://blog.csdn.net/wei_yongtao/article/details/40145891
http://www.cnblogs.com/itech/archive/2012/05/15/2502284.html

inode

在介绍问题之前，先简单介绍一下linux中文件的inode节点。
在linux中，每一个文件都有一个inode节点，包含了文件的元信息，如下所示：

• 文件的字节数
• 文件拥有者的User ID
• 文件的Group ID
• 文件的读、写、执行权限
• 文件的时间戳，ctime, mtime 和 atime
• 链接数，即有多少文件名指向这个inode
• 文件数据block的位置

可以使用 stat 文件名 查看文件的inode信息

ls -i
df -i
stat filename

在linux中，每一个文件都有inode节点，每一个inode节点都有一个inode编码，操作系统通过这个编码来识别不同的文件。表面上，是通过文件名打开文件，实际上，系统内部这个过程可分为三步：

1. 系统找到这个文件所对应的inode编码
2. 通过inode编码获取inode信息
3. 根据inode信息，找到文件数据所在的block，然后读取数据。

替换运行程序

Linux中由于Demand Paging（内存映像和需求分页）机制的关系，必须确保正在运行的程序镜像(并非文件本身)不被而已破坏，因此内核在启动程序后，会锁定这个程序镜像的inode。

当程序正在运行时，比如当前正在运行的程序名为test1，如果你使用

cp test2 test1

的方法直接覆盖正在运行的程序的话，会报错，且提示file busy。这是因为cp命令并不是重新创建一个新的文件test1，而是打开test2和test1，然后将test2的内容写入到test1中，得到的新的test1文件会继承原test1文件的属性，inode编号不变，但是文件大小和时间等信息会发生改变，这就是说，改变了inode。但是程序是正在运行的，内核在程序启动后就锁定了程序镜像的inode节点，所以这个cp命令会失败。

strace cp test2 test1

就可以发现这个命令底层系统调用的信息。为了让大家方便的看到，做一个实验，创建两个内容不停的文件，分别命名为test1和test2

stat test2

查看test2文件的inode信息如下所示

再查看test1文件的inode信息

当使用

cp test2 test1

查看test1文件的inode信息

当test1文件被覆盖之后，文件大小发生了变化，但是inode编号并没有发生变化，如果新创建了一个文件呢

cp test2 test

查看test文件的inode信息

新创建的test文件的inode是新的节点，编号与之前都不相同。

所以，如果想替换正在运行的程序，需要先删除文件，然后在拷贝

rm test1
cp test2 test1

这样才不会出现问题，这是因为cp和rm的差异造成的，cp覆盖文件，目标文件会继承源文件的属性，这就导致文件的inode发生了变化，这是不允许的；但是如果先删除目标文件，新的文件的inode已经发生了变化，而原inode信息并没有发生改变，它被内核所锁定，直到内核释放对它的引用。同理，使用mv只会修改文件名，并不会改变inode，新创建的文件会使用新的inode，这两种方法替换正在运行的程序都不会出错。

mv test1 test_bak
cp test2 test1

替换so共享库文件

当一个后台执行的程序，使用cp直接替换它引用的动态库文件时，会出现segmentation fault的错误，错误原因跟上面类似，可以采用rm + cp的方法替换，程序在运行过程中，如果删除动态库文件并不会发生错误，此时，如果想让新的动态库文件生效，还必须重新启动程序。

但是在大型程序中，比如nginx中，当系统升级更新动态库文件时，并不需要重启程序，首先nginx程序会将master进程的pid文件重命名，然后启动一个新的程序（这样就不会因为pid文件的原因导致程序重复启动的冲突问题发生），启动成功后，再停止旧的程序，实现程序的平滑升级。