I have a situation where I observe that BackupPC stalls for a particular host. This host runs Debian 10 (and has e.g. Docker installed).

During that situation, two rsync-related processes are running on that host (parent sudo /usr/bin/rsync --server ... and child /usr/bin/rsync --server ...). When I try to find out which file rsync is currently handling (i.e. where it stalls) by issuing lsof -p $child_pid, this also stalls (i.e. it apparently never returns but can be stopped e.g. with Ctrl-C). ls /proc/$child_pid/fs works fine at the same time (and returns only 4 fds).

So perhaps this is close to the root cause why rsync is stalling. How can it be the case that lsof -p is stalling esp. when ls /proc/$child_pid/fd is not? Should it not always come back with an (almost) immediate answer? And how can I further diagnose the situation (as well as then resolve it)?

UPDATE I am now checking for fragmentation in ext4 file systems on that host. This also takes a long time ...

time e4defrag -v -c $(df -t ext4 | tail -n +2 | awk '{print $1}')

UPDATE By now it looks as if e4defrag -v -c is stuck; its last output reads "/media/cdrom0" File is not regular file. The host is in fact a Proxmox VM, so could the issue perhaps be related to its virtual CD-ROM? This seems unlikely though, because df /media/cdrom0 indicates it is mounted on /, and if I am not mistaken e4defrag is already past this file system and now into /var. Perhaps /var (size 23G) is so heavily fragmented that a long duration is normal or perhaps e4defrag hits some limitations.


In the end, this looked related to "orphaned" files apparently stemming from NFS mounts into containers at a time when an NFS server could not be reached. Once I identified and removed those (e4defrag and) lsof were no longer stallingm, i.e. behaved again as expected.

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.