In Linux, how does one know that the file was written by that process? in the evening, a student asked: a file is being written by a process. I want to check that this process file is always increasing and cannot be found.
In the evening, Shuohai asked:
A file is being written by a process. I want to check whether the process file is being enlarged and cannot be found. no one is writing or using lsof.
This problem is quite universal, and there should be many solutions. here I will give you a more intuitive method.
In linux, each file is stored on a block device, and of course there are corresponding inode. write, we can know who is constantly writing inode to a specific device.
Fortunately, the systemtap installation package contains inodewatch. stp, which is located in the/usr/local/share/doc/systemtap/examples/io directory for this purpose.
Let's take a look at the code:
$ cat inodewatch.stp #! /usr/bin/env stapprobe vfs.write, vfs.read{ # dev and ino are defined by vfs.write and vfs.read if (dev == MKDEV($1,$2) # major/minor device && ino == $3) printf ("%s(%d) %s 0x%x/%un", execname(), pid(), probefunc(), dev, ino)}
The script is used as follows: stap inodewatch. stp major minor ino
Next we construct a scenario: dd keeps writing a file, finds the ino of the file, and the major, minor, of the device where it is located, and runs the stap script to get the answer.
The scenario has been explained. Let's demonstrate the following:
$ pwd/home/chuba$ dfFilesystem 1K-blocks Used Available Use% Mounted on.../dev/sdb1 1621245336 825209568 713681236 54% /home...$ ls -al /dev/sdb1brw-rw---- 1 root disk 8, 17 Oct 24 11:22 /dev/sdb1 $ rm -f test.dat && dd if=/dev/zero of=test.dat^C9912890+0 records in9912890+0 records out5075399680 bytes (5.1 GB) copied, 26.8189 s, 189 MB/s
This terminal simulates the continuous writing of files, and checks who did it on another terminal. Here we know that the major/minor of the device is 8/17
$ stat -c '%i' test.dat25337884$ sudo stap /usr/local/share/doc/systemtap/examples/io/inodewatch.stp 8 17 25337884dd(740) vfs_write 0x800011/25337884dd(740) vfs_write 0x800011/25337884dd(740) vfs_write 0x800011/25337884dd(740) vfs_write 0x800011/25337884dd(740) vfs_write 0x800011/25337884dd(740) vfs_write 0x800011/25337884...
As you can see, dd is the culprit, and pid is 740. close the job!
Conclusion: systemtap is an amazing tool to solve this problem.
Have a good time!