However fuser is useful when it comes to killing the processes causing your dramas so you can get on with your life. There is an advantage to using /dev/ rather than /mountpoint: a mountpoint will disappear after an umount -l, or it may be hidden by an overlaid mount.įuser can also be used, but to my mind lsof has a more useful output. Processes with open files are the usual culprits. I'm not sure whether quotas could ever prevent an unmount - I was clutching at straws. dev/loop1: :59 (/mnt/big/dot-dropbox.ext2)Ī Gentoo forum post also lists swapfiles as a potential culprit although swapping to files is probably pretty rare these days, it can't hurt to check the output of cat /proc/swaps. dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=er 0 0 Usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0ĭevpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0įusectl /sys/fs/fuse/connections fusectl rw 0 0 Tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0 dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0 None /proc proc rw,nosuid,nodev,noexec 0 0
None /sys sysfs rw,nosuid,nodev,noexec 0 0 I'd already checked the output of fuser -vm / lsof +D, mount and cat /proc/mounts, checked whether some old nfs-kernel-server was running, turned off quotas, attempted (but failed) a umount -f and all but resigned myself to abandoning 924 days' uptime before finally checking the output of losetup and finding two stale configured-but-not-mounted loopbacks: parsley:/mnt# cat /proc/mounts To add to BruceCran's comment above, the cause for my manifestation of this problem just now was a stale loopback mount.
0 kommentar(er)
