Linux中文件执行中的锁定怪现象解释

本来今天不准备开电脑了，太困了，想睡觉，然而一哥们儿短信都发过来了，要问个问题，于是还是打开了电脑，没想到是一个很有代表性的问题，顺便也牵扯了前些天我的工作中的一个bug，值得记录下来。问题如下： 

linux下，一个可执行文件exe1正在执行中，rm –f可以将其删除，mv可以将其移除，mv $other exe1也可以将其替换，但是cp $other exe1则显示文件忙，求解。 

这实际上并不是一个真正的问题，因为只要你的基础知识扎实，这个问题显然很简单，原因只有一个，那就是linux文件基于引用计数。现在问题是这些个命令如何来操作一个文件的引用计数。下面的讨论都是基于独占打开的模式。 

如果一个文件已经被打开，那么它的引用计数会增加1，如果调用了rm，实际上底层只是unlink了一下，也就是说将它的引用计数减少1，这样虽然你在界面上(命令行或者GUI)看不到它了，但是它被打开时的计数还在，只有当它被关闭的时候，引用计数变为0，才彻底删除它。 

再说mv命令，它实际上只是一个源文件的rename而已，如果mv的目标本来就存在，那么在目标上执行一个类似rm的效果，也就是unlink一下，结合引用计数的理论，目标文件如果已经被打开，那么当关闭的时候将不复存在，如果本来就没有被打开，那么mv的时候，目标直接被删除，因为unlink之后，它的引用计数变成了0。 

最后看一下cp命令，cp的话并不触动源文件和目标文件元数据本身(时间戳除外)，它只是打开源文件和目标文件，在源文件上执行read，然后将结果write到目标文件，实质上是一个IO操作，对于可执行文件，是独占打开的，并不允许写入，因此会出错。 

这里就不再列出内核源码了，可以自行参考系统调用的实现而加深理解，不过最好别干巴巴的看，还是结合strace以及objdump比较好，要知道是怎么以及什么时候调用的，以及调用参数是什么，否则就和八股文没区别了。那么这和我工作中的bug有什么关系呢?这个bug源于OpenVPN的日志记录，并且配置了日志回滚，回滚配置文件关键字段如下： 

size 4M 

missingok 

rotate 9 

compress 

delaycompress 

create 644 xx xx 

… 

结果当日志回滚成了vpn.log.1之后，这个vpn.log.1依然继续被写入。这个原因正是rename造成的。在logrotate的man页面中，有一个copytruncate配置，其含义就是不进行rename，而只是copy，然后将原来的文件truncate，加入这个就可以了。 

千万不要小看这些很简单的命令，真正理解的人并不多，即使真正的理解，出现问题，能真正对应到原理也不多，很简单的东西如果能彻底做到透彻的理解并且活用，再往深入学习才是有意义的。