Listing the files that are being watched by `inotify` instances

Question

I got a little script that lists the number of inotify watches per process. That usually gets me what I want, but now I would like to know which files are being watched. I assume this is possible and that a inotify watch corresponds to a file being monitored by an inotify instance?

I also assume that I can build upon what I currently have in that script. For instance,

sudo find /proc/*/fd -lname anon_inode:inotify  | cut -d "/" -f 3

gets me a list of processes with inotify file descriptors. If I look at the info for one of the file descriptors, I get what I assume is a list of file handles/watches:

$ sudo cat /proc/50679/fdinfo/19
pos:    0
flags:  00
mnt_id: 15
inotify wd:8 ino:640001 sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:01006400feaad211
inotify wd:7 ino:a08da sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:da080a0094019e8f
inotify wd:6 ino:840003 sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:030084005ae9e3df
inotify wd:5 ino:840002 sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:020084000d506c1f
inotify wd:4 ino:840001 sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:01008400e47bab26
inotify wd:3 ino:32004e sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:4e003200488122df
inotify wd:2 ino:320001 sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:01003200545a9f32
inotify wd:1 ino:2 sdev:800001 mask:3cc ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:0200000000000000

I was hoping I could find out which file f_handle:01003200545a9f32 corresponds to, basically translate a f_handle in /proc/../fdinfo/ to a file name.

Answer 1

I don't know about standard tools that deal with the f_handle field. That would be convenient what with the open_by_handle_at(2) syscall, but anyways that field may not always be valid. The kernel's nfsd for instance does not provide it.

However, the full coordinates of any file in Linux are still the good-old device number and inode number, which are reported in the sdev and ino fields. It's only a matter of decoding them.

Those two values are (currently) expressed in hexadecimal notation. You can take the ino as is, just convert it into decimal notation.

The sdev value on the other hand needs some decoding because you need to split it into the traditional "major and minor" device numbers. Note that even files residing in filesystems not backed by actual block-devices still carry a unique pseudo-device number, which is reported in that sdev field.

Assuming that the sdev field is encoded according to Linux's so-called "huge encoding", which uses 20 bits (instead of 8) for minor numbers, in bitwise parlance the major number is sdev >> 20 while the minor is sdev & 0xfffff. Or using a layman text-manipulation approach, the minor number is the rightmost (up to) 5 hex-digits while the major number is everything before the final 5 hex-digits. If there are fewer than 5 hex-digits, the major number is simply 0.

Once major & minor are obtained, you go looking for them into the target process's mountinfo file. In your example that would be /proc/50679/mountinfo. Specifically you look for a line carrying such major:minor pair as third field. The found line's fifth field is the path you need for a final find that goes hunting for the wanted file/dir.

Note: major & minor obtained from an inotify line in /proc/*/fdinfo/* are expressed in hex-notation, but in mountinfo are expressed in decimal, so you need to convert them before searching them in mountinfo.

Note: the fifth field in mountinfo may contain \-escaped octal sequences in case the \ itself or <space>, <newline>, <tab> characters are part of the path. Meaning that a whitespace is encoded as \040, a \ as \134, and so on. You can unescape those by e.g. feeding that path to printf(1)'s own %b specifier.

Note: in order to account for namespaces (i.e. containers) you need to run the final find command within the mount-namespace that the target process lives into, hence for instance something like (for your example):

nsenter -mt 50679 find "$unescaped_path" -inum "$decimal_ino" -print -quit