Explanation of the locking strange phenomenon in file execution in Linux

I wasn't going to start the computer today. Too sleepy, want to sleep, but a buddy text messages are sent over, to ask a question, so or open the computer, did not think is a very representative problem, incidentally also involved a few days ago I work in a bug, worth recording down. The questions are as follows:

Linux, an executable file exe1 is in execution, rm–f can remove it, MV can remove it, MV $other Exe1 can also replace it, but the CP $other EXE1 will show the file busy, solve.

This is not really a real problem, because as long as you have a solid foundation, the problem is clearly simple, because there is only one reason that Linux files are based on reference counting. The question now is how these commands manipulate the reference count of a file. The following discussion is based on an exclusive open mode.

If a file has been opened, then its reference count will increase by 1, if the call to RM, the bottom is actually just unlink, that is, the reference count is reduced by 1, so although you can not see it in the interface (command line or GUI), but it was opened when the count is still, Only if it is turned off, the reference count becomes 0 before it is completely removed.

Besides MV command, it is actually just a source file of the rename, if the goal of the MV is there, then perform a similar effect on the goal of RM, that is, unlink, combined with reference counting theory, the target file if it has been opened, then when the shutdown will no longer exist, If it has not been opened, then when the MV, the target is deleted directly, because after the unlink, its reference count has become 0.

Finally, look at the CP command, CP words do not touch the source file and the target file metadata itself (except the timestamp), it is only open source files and target files, execute read on the source file, and then write the result to the target file, essentially an IO operation, for the executable file, is exclusive open, Writing is not allowed, so there is an error.

Here will no longer list the kernel source code, you can refer to the implementation of the system call to deepen understanding, but it is best not to look at the dry, or combined with strace and objdump better, to know how and when the call, as well as the call parameters are no different from the confucianism、the. So what does this have to do with the bugs in my job? This bug originates from OpenVPN logging, and the log rollback is configured, and the Rollback profile key fields are as follows:

Size 4M

Missingok

Rotate 9

Compress

Delaycompress

Create 644 xx XX

...

As a result, the Vpn.log.1 continues to be written after the log rolls back to Vpn.log.1. This is precisely the cause of rename. In the Logrotate man page, there is a copytruncate configuration, which means not to rename, but copy, and then the original file truncate, to join this on it.

Do not underestimate these very simple commands, really understand the people are not many, even if the real understanding, there are problems, can really correspond to the principle is not much, very simple things if you can thoroughly understand and flexible, and further study is meaningful.