I have this more frequently with not well-behaved FUSE filesystems. Those processes cannot be killed and suspend will not work anymore because those processes also cannot be frozen: Freezing of tasks failed after 20 seconds (2 tasks refusing to freeze, wq_busy=0):.
Sometimes the process hangs because of a faulty file system. In that case, try forced umount:
sudo umount -f /path-to-problematic-mount-like-sshfs I already tried to lazily unmount it and had lost my mount point. The solution that worked for me was to use the FUSE control file system to abort the problematic connections. Quote from the link:
waiting The number of requests which are waiting to be transferred to userspace or being processed by the filesystem daemon. If there is no filesystem activity and ‘waiting’ is non-zero, then the filesystem is hung or deadlocked.
abort Writing anything into this file will abort the filesystem connection. This means that all waiting requests will be aborted an error returned for all aborted and new requests.
Finding the correct connection is cumbersome. In my case it was easy because all other FUSE file systems had no activity and one of the FUSE connections had 2 waiting requests no matter how often I polled. I aborted that connection and after that the process exited as desired.
for fuseConnection in /sys/fs/fuse/connections/*/; do waiting="$( cat -- "$fuseConnection/waiting" &>2> /dev/null )" if [ -n "$waiting" ] && [ "$waiting" != 0 ]; then echo "$fuseConnection has waiting requests." fi done If you are sure that you got the correct connection, then you can abort it by writing anything to the special abort file. Note that this might interrupt file transfers and such when done on the wrong connection. I'm not yet aware of a better method to find out which connection belongs to which mount.
echo 1 > /sys/fs/fuse/connections/1234567890/abort