[Reprint] A Linux program to replace files during the run

I was asked by my friend today, "Can I replace a running program under Linux?" "I used to vaguely remember that Linux was OK (and Windows did not), so I answered" okay "casually. Result a friend sends an execution result: (test is running)
# CP Test2 Test Cp:cannot Create regular file ' Test ': Text file busy

It appears that the program is occupied and cannot be overwritten. So I did a few more experiments:

(1) RM first deletes the running test, then the CP test2 Test has no errors.
(2) First MV Renaming is running test, then CP test2 test also no problem.

Check the data and do a hands-on analysis, found a more satisfactory explanation. The CP does not change the inode of the target file, in fact it is implemented like this:
# strace CP test2 Test 2>&1 | grep open.*test Open ("Test2", o_rdonly| O_largefile) = 3 Open ("Test", o_wronly| o_trunc| O_largefile) = 4

I thought the CP implementation was "RM + open", but now think of the o_creat implementation as the most reliable (guaranteed timing security and the properties of the target file). This can also explain why the target file for CP inherits the properties of the overwritten file rather than the source file.

Linux due to the demand paging mechanism, it is important to ensure that the running program image (note, not the file itself) is not accidentally modified, so the kernel will lock the inode of the program image after launching the program. That's why CP is using the o_wronly| O_trunc "mode open target file will fail. In the case of RM and CP, the inode of the new file has changed, and the original inode is not actually deleted until the kernel releases a reference to it. In the same way, the MV simply changes the file name, its inode is unchanged, and the new file uses the new inode.

The problem has come to an end here, but Root planing's personality drove me to do the following group of experiments, I did not expect the results completely unexpected!

Wrote a simple test program:
#include <stdio.h> int main (int argc, char * argv[]) {foo (); An export function by libtest.so. Sleep (1000); return 0; }

Foo () is another export interface that tests the dynamic library libtest.so, and returns with a single line of hints printed. Next I'll do the test case for the execution file on the dynamic library again:

(1) CP libtest2.so libtest.so can directly overwrite the loaded dynamic library.
(2) RM first deletes the loaded libtest.so, then the CP libtest2.so Libtest.so succeeds.
(3) First MV renamed the Loaded libtest.so, then the CP libtest2.so Libtest.so succeeded.

Except for the first one with the exception, the result is the same. So, does the LD not lock the inode when the dynamic library is loaded? But to think can also forgive, after all, LD is also a user-state program, there is no right to lock the inode, and should not be coupled with the kernel's filesystem bottom-up implementation.

It is reasonable to be here, and it seems that Linux is well handled. But there is still one question: Will the dynamic library be overwritten with the CP and not be conflicted with the demand paging mechanism?

In the process of thinking about the problem, I realized that a fatal flaw in the previous test program was slightly modified as follows:
#include <stdio.h> int main (int argc, char * argv[]) {Loop:foo (); An export function by libtest.so. Sleep (1); Goto Loop; return 0; }

This time, after executing the above three use cases, it was found that "CP libtest2.so libtest.so" could still directly overwrite the loaded dynamic library, but the test program immediately appeared "Segmentation fault". Then the two use case results are unchanged. This shows that you want to safely replace the loaded dynamic library, or the "clumsy" RM + CP, seemingly short-cut "CP coverage" will directly destroy your program ...

It seems that once again I underestimate the robustness of Linux, and seemingly logical processes can have disastrous consequences; the underlying differences behind the RM & CP and CP overlays can be your savior. The longer Linux is used, the more it feels like a primitive jungle full of thorns and traps, and it takes a step forward to go farther.

Note: The above experiments are based on SUSE Linux Enterprise Server 9 SP1 (Linux 2.6.5 & glibc 2.3.3).

[Reprint] A Linux program to replace files during the run