-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unmounting FUSE through FileSystemHost cleanly #6
Comments
The problem
The problem is that FUSE does not have a clean way to unmount a file system. Instead it has a function for signaling the FUSE loop that it can exit. This function is called
The other problem is that the FUSE layer handles its own signals. It is rather perilous to attempt to change signals in a FUSE program without understanding all the details of the FUSE loop. Here is a very interesting thread that discusses problems with signal handling and http://fuse.996288.n3.nabble.com/libfuse-exiting-fuse-session-loop-td10686.html
What is likely happening here (keep in mind I am still a Go novice):
How to fix thisThere are unfortunately no easy fixes. Here are a few ideas:
Unmount on LinuxWe cannot issue the Unmount on OSXOSX allows issuing an Unmount on WindowsOn WinFsp-FUSE |
Thank you for the expansive answer! I see the dilemma. Let me take some time to think about a possible solution for my case and I'll share the results. This way we may find a suitable middleway. |
@advanderveer thanks. I have actually been working for a solution in the last couple of hours. But I will be happy to see what you come up with. |
BTW, my experiment is in the hostMain branch. |
Commit 9277768 fixes this. Please test under your scenario and let me know. |
This does what I expect it to do on Linux and OSX (Cool!). On windows, having the winfsp capture of the signal is unexpected and I'm not sure how to work around it, but i'll do some research myself for that. If I find anything i'll post it here for future reference. The main issue is fixed so i'll close this |
@advanderveer I am glad that [NOTE:
When I was writing the WinFsp-FUSE layer, I did try to implement the libfuse signal semantics. Unfortunately this is not possible on Windows, because of the lack of true signal support. Are you trying to cleanup just before your file system exits (through a signal or otherwise)? It might be worth trying to fix this in cgofuse (or even in WinFsp), so that cgofuse clients do not have to worry much about the specifics of the underlying implementation. So please do share your research findings if/when you have them. UPDATE: For example, we could add a guarantee that |
Unfortunately i'm not aware of what a "normal" fuse impelementation is supposed to do with signals but i'm simply trying to make sure that a user who start my CLI application (that mounts a file system while running) exits with the users system in the shape it was before running my application. I found that the following does what I want:
As a user of this library I expected to be able to use signal.Notify on windows as I would in other Go programs. It might have something to do with how golang implements signal handling on windows: here Unfortunately i'm not knowledgable about either FUSE or windows to know if the way I expect it to act is sensible and the solution I describes above is statisfactory. You wouldn't need to go through hoops for a better solution but maybe it is possible to configure the signal capturing on windows (opt in) such I can decide to call unmount myself on windows as well? |
I had a read at golang's "signal" support for windows:
Unfortunately this assumes that the golang runtime is the only entity handling ^C in a golang program. This is not true in our case. [Windows allows multiple handlers for "console ctrl events".]
This would have to be changed on the WinFsp-FUSE layer. Unfortunately a change like this would be problematic for a number of reasons. Since you have a solution for this I propose that we:
These guarantees would be:
Of course this proposal does not do what you want (allow |
I think the I have some almost identical code in rclone for unmounting on a signal which I'll wrap in |
I believe the reason is both historical and technical, but I am not the right person to answer this question. Here is an interesting thread on this subject (I do not necessarily agree with their reasoning): https://sourceforge.net/p/fuse/mailman/message/30221453/
So I gather that there is no perceived need to have this fixed in cgofuse then. |
Hmm, interesting thread...
I think documenting the difference would be fine. |
I wrote:
Heads up! The fact that cgofuse wants to be cross-platform, but did not deal with the differences between unmounting behavior on different platforms, kept bothering me. So I decided to fix it tonight. Commit 047c3f8 adds the aforementioned guarantees. This is currently on the auto-unmount branch, but I will be merging into master soon. BTW, this commit does not currently handle |
I think that making extra cross platform guarantees is a great idea :-) Love the idea of no more zombie mounts. (I can't suspend my laptop at the moment because I have about 20 zombie mounts ;-) Why are you worried about SIGPIPE? Does kernel use SIGPIPE to talk to libfuse or something? I think go's handling of sigpipe will mean that it doesn't exit normally. |
Great. This is now merged into master.
It is another signal that may kill a FUSE program thus leaving zombie mounts. Libfuse normally handles it by ignoring it. Golang's handling of So cgofuse currently gets notified (and cleans up) on |
Great work on getting such a clean interface for cross platform FUSE! When I was trying this out today I couldn't get the Filesystem to unmount cleanly though. For example, adapting the memfs example's main() like this causes the filesystem to hang around when the program exits:
on OSX/Linux the Unmount() doesn't seem to do anything, on Windows the library itself seems to unmount but not under control of my own program but rather somewhere inside cgofuse itself.
The text was updated successfully, but these errors were encountered: