Shulou(Shulou.com)06/01 Report--

This article will explain in detail the analysis of the strange locking phenomenon in the implementation of Linux files. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Under linux, an executable file exe1 is being executed, rm-f can delete it, mv can remove it, and mv $other exe1 can replace it, but cp $other exe1 shows that the file is busy and solved.

This is not really a real problem, because as long as you have solid basic knowledge, the problem is obviously simple for only one reason, that is, 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 the exclusive open mode.

If a file has been opened, then its reference count will be increased by 1, if rm is called, the bottom layer is actually just unlink a bit, that is to say, reduce its reference count by 1, so that although you can't see it on the interface (command line or GUI), it still has the count when it is opened, and only when it is closed, the reference count changes to 0 before it is deleted completely.

In addition, the mv command is actually just a rename of a source file. If the target of mv already exists, then execute a rm-like effect on the target, that is, unlink, combined with the theory of reference counting, if the target file has been opened, it will no longer exist when it is closed, and if it is not opened in the first place, then the target will be deleted directly in mv, because after unlink Its reference count becomes 0.

Finally, take a look at the cp command, cp does not touch the source file and target file metadata itself (except the timestamp), it just opens the source file and the target file, executes read on the source file, and then write the result to the target file, which is essentially an IO operation. For executable files, it is opened exclusively, and writing is not allowed, so errors will occur.

The kernel source code is no longer listed here, and you can refer to the implementation of the system call to deepen your understanding, but it's best not to look at it dryly, it's better to combine strace and objdump, to know how and when it was called, and what the call parameters are, otherwise it will be no different from the eight-part essay. So what does this have to do with my bug at work? This bug is derived from the logging of OpenVPN and is configured with log rollback. The key fields of the rollback configuration file are as follows:

Size 4M

Missingok

Rotate 9

Compress

Delaycompress

Create 644 xx xx

...

As a result, after the log is rolled back to vpn.log.1, the vpn.log.1 continues to be written. This reason is caused by rename. In the man page of logrotate, there is a copytruncate configuration, which means that there is no rename, but just copy, and then add the original file truncate to this.

Do not underestimate these very simple commands, there are not many people who really understand, even if they really understand and have problems, there are not many things that can really correspond to the principle, if very simple things can be thoroughly understood and used flexibly, further study is meaningful.

On the "Linux file implementation of the lock strange phenomenon analysis" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.