clone 478287 -1 reassign -1 fuse tags 478287 moreinfo thanks > On a live system the / filesystem is usually a union mount of a readonly > base and a tmpfs overlay. The initscripts try quite hard to break the > filesystem if the base is mounted from the network:
How is this specific to operations from the network, and not just any FUSE root filesystem? > They kill all processes including processes that support FUSE filesytems > (and probably nfs/smbfs/cifs as well) in sendsigs (and probably > killprocs). Is this still an issue nowadays? If it is, then relevant FUSE processes can and should register in /run/sendsigs.omit.d/ to avoid getting killed by /etc/init.d/sendsigs Steve, I saw you explain in one bug report that there was no such process supporting CIFS. Can you confirm about NFS, SMBFS or others that you know about, if they rely on any process that wouldn't already be protected in /run/sendsigs.omit.d/ ? > They also umount all filesystems with umount -f which kills the FUSE > filesystem. The comment explicitly says it is menat to kill NFS > filesystems. Which comment, where? I assume that we're talking about /etc/init.d/umountfs calling umount -f; however this script does not attempt to unmount / (and neither /usr now), so in that case you describe I don't understand how that could be an issue. > Both can cause ugly error messages on shutdown or even prevent the > shutdown completely if the filesystem is unmounted and poweroff or > halt is not cached. > > I have seen this problem with httpfs root on a live Debian system. > However, this could possibly cause problems with any setups where the > / filesystem is on the network. A / filesystem on the network could indeed experience issues with the -i option passed to halt in /etc/init.d/halt (#499796, #632091), but that's separate from umount issues. Please note how /etc/init.d/networking is aware of handling two FUSE network filesystem types: fuse.httpfs (used in this case) and fuse.curlftpfs. Are there others to handle? > In /etc/init.d/umountfs all filesystems except tmpfs are umounted with > the force "-f" flag. While I already think it is a bad idea to use > the special force flag for everything, it causes real trouble with > fuse-filesystems. For fuse-filesystems the force flag will close the > /dev/fuse connection and thus the filesystem will abort. If there are > still open filedescriptors on the mount point, all further access to > these mount points will return "Transport endpoint is not connected" > (errno 108). At this point of the shutdown sequence, there should be nothing left using the filesystems that are to be unmounted, so I don't really understand this. And forced unmounting will cause errors with later access attempts on any filesystem, not just FUSE, so I don't see how that's specifically worse of a problem with FUSE. Finally, simply not unmounting the filesystems might avoid those error messages, but I don't think that really solves the problem. Can you explain better, or mention what would still be using FUSE filesystems when it's time to unmount them? > I also think this should be fixed in fuse, however, the author of fuse > thinks the present behaviour is correct and so there is presently no > way to fix it at kernel level. Please see this thread: > http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6579/focus=6592 This URL doesn't seem to work now. I personally have no experience with FUSE. Dear fuse maintainers, could you please help and: - look into this issue about FUSE filesystem processes getting killed at shutdown? - advise about anything that I might have failed to understand about the unmounting issue? - advise about FUSE network filesystem types and how to detect them? Thanks, -- Pierre Ynard
