我遇到过这样的情况：我观察到特定主机的 BackupPC 停止运行。该主机运行 Debian 10（并且安装了 Docker）。
在这种情况下，rsync该主机上正在运行两个相关的进程（父进程sudo /usr/bin/rsync --server ...和子进程/usr/bin/rsync --server ...）。当我尝试通过发出 来找出rsync当前正在处理哪个文件（即它停止的位置）时lsof -p $child_pid，这也会停止（即它显然永远不会返回，但可以使用 Ctrl-C 停止）。ls /proc/$child_pid/fs 工作正常同时（并且仅返回 4 个 fd）。
所以也许这接近rsync停滞的根本原因。怎么会出现这种情况呢lsof -p？什么时候ls /proc/$child_pid/fd不是？它不应该总是（几乎）立即返回答案吗？我怎样才能进一步诊断这种情况（然后解决它）？
更新我现在正在检查ext4该主机上文件系统中的碎片。这也需要很长的时间...
time e4defrag -v -c $(df -t ext4 | tail -n +2 | awk '{print $1}')
更新现在看起来好像e4defrag -v -c被卡住了；它的最后一个输出为"/media/cdrom0" File is not regular file.该主机实际上是一个 Proxmox 虚拟机，那么问题可能与其虚拟 CD-ROM 有关吗？但这似乎不太可能，因为df /media/cdrom0表明它安装在 上/，如果我没有记错的话，e4defrag它已经通过了这个文件系统，现在进入了/var。也许/var（大小23G）碎片化程度太高，持续时间长是正常的，或者可能e4defrag会命中一些限制。
答案1
最后，这看起来与“孤立”文件有关，这些文件显然是由于在无法访问 NFS 服务器时将 NFS 安装到容器中而产生的。一旦我识别并删除那些（e4defrag和）lsof就不再停滞，即再次按预期运行。