我读过一些umount -l不安全的地方：

在@cas 的回答中：

如果您关心何时可以安全地拔下外部驱动器，请不要使用umount's--lazy选项

@frostschutz 的评论：

umount --lazy是不安全的，也不能变得安全。[...]

这util-linux 通过Ruediger迈耶评论：

你应该完全避免使用umount -l。只需杀死所有正在使用的进程，/tmp/mountpoint然后不带选项 umount 即可-l。

为什么umount -l不安全/危险？

有没有办法让它安全？

我如何获得以下列表：

• 当前正在监视的路径名inotify，以及
• 进程监控的PID

我问是因为我发现syncthing'sinotify手表阻止我的磁盘被卸载。

如下所示，没有任何内容出现在lsof或fuser列表中。

我猜对了syncthing......如果磁盘因以下原因无法卸载，我该如何消除未来的猜测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

问题

在umount -l某个已挂载的文件系统上执行之后，并且该文件系统仍然处于挂载状态（尽管是隐藏的），因为某个进程（至少）维护了该文件系统上某些文件的一个打开的文件句柄，如何可靠地获取此类进程的列表?

测试设置

我执行了以下步骤来创建这样的情况并在系统中四处探索并尝试各种命令（在带有 linux 3.16 内核的 debian jessie 上使用 bach）：

sudo -i
cd $(mktemp -d) # get empty directory to play around with
# create empty file system with one file
dd if=/dev/zero of=disk bs=1M count=4
mkfs.ext4 disk
# mount the filesytem and create a file
mkdir mounted
mount disk mounted # uses /dev/loop0 in my case, actual device my vary
touch mounted/file
# fork of a process with an open file handle to file
bash …