5

How do I get a list of:

  • Pathnames currently being watched by inotify, and
  • PID of the process watching

I ask because I have found that syncthing's inotify watches were preventing my disk from being unmounted.

As can be seen below, nothing appears in lsof or fuser listings.

I guessed well with syncthing... How do I remove the guesswork in future if a disk won't unmount due to inotify?


# umount /media/backup
umount: /media/backup: target is busy.
# lsof +f -- /media/backup/
# echo $?
1
# fuser -vmM /media/backup/
                     USER        PID ACCESS COMMAND
/media/backup:       root     kernel mount /media/backup
# systemctl stop syncthing@ravi
# umount /media/backup
# echo $?
0
4

Maybe the fdinfo for the fd of the watch can be useful:

$ readlink /proc/$(pgrep inotify)/fd/3
anon_inode:inotify
$ cat /proc/$(pgrep inotify)/fdinfo/3
pos:    0
flags:  00
mnt_id: 11
inotify wd:1 ino:357a sdev:700000 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7a35000000000000

The sdev seems to be the major:minor device number combination, as seen in the output of lsblk, for example:

$ lsblk | grep 7
loop0    7:0    0  80.5M  1 loop /snap/core/2462

(I was indeed monitoring /snap/core/2462.)

For my /dev/sda1 which is 8:1, the output looked like so:

pos:    0
flags:  00
mnt_id: 11
inotify wd:1 ino:aae1b sdev:800001 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:1bae0a0038e16969

This should be sufficient to find out what's blocking unmounting, even though the specific directories or files being watched aren't listed.

  • Great lead. Using mnt_id as an index into /proc/[pid]/mountinfo would give the mountpoint directory. How to efficiently perform this check for all processes (irrespective of name)? – Tom Hale Aug 18 '17 at 8:50
  • 1
    man proc(5) says sdev: The ID of the device where the target file resides (in hexadecimal). It also explains mnt_id and the mountinfo file. – Tom Hale Aug 18 '17 at 8:59
1

(WIP Answer)

Thanks to muru's answer for the kickstart.

Using the information in /proc/[pid]/fdinfo/[fd#]:

Possibly lsof: list only files of a particular type with a_inode.

Too slow as a shell script with all the greping. Perhaps system call interface to /proc information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.