When a fuse file system is unmounted it sends upcall FUSE_GETATTR to the user space file system. If the user space file system does not respond fuse will block umount indefinitely. Only root can then force unmount. I noticed this using davfs2 which does not use the fuse library but directly reads and writes to /dev/fuse. When davfs2 gets SIGTERM it will stop reading from /dev/fuse and (after cleaning up) call "umount -il <mount point>" (using system(3)). I am quite sure (but not absolutely sure) this worked with fuse kernel version 7.5 but don't know when the change happend. Anyway: a user space file system may crash or not respond for many reasons. This should not block fuse and umount. This bug may be related to Bug 115951. Exact kernel version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) davfs2: http://cvs.savannah.gnu.org/viewvc/davfs2/?root=davfs2&pathrev=rel-1-5-2 Relevant files: src/dav:fuse.c and src/mount_davfs.c Werner
Created attachment 212031 [details] Tracing syscalls of umount when user space file system does not respond
Created attachment 212041 [details] Tracing syscalls of umount when user space file system is dead
I have added two syscall traces of umount that show where unmounting fails. umount issues lstat for the mountpoint (probably trying to canonicalize the file name of the mountpoint). - If the user space file system is still running and holds /dev/fuse open, fuse will send upcall FUSE_GETATTR. User space does not respond and lstat and mount hang forever. - If the user space file system is dead and /dev/fuse is closed, fuse will return error ENOTCONN and umount terminates with an error. Additional remark: davfs2 can use the coda kernel module instead of fuse. With coda the problem does not exist. Probably coda caches enough information about the mountpoint (the root of the file system) to answer lstat without upcall to the userspace. Werner