Bug#492176: FUSE filesystems improperly killed at shutdown

[Pierre Ynard]

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