Unmounting internally from the controller process leaves dangling transport endpoint on mount point

[shreyanshk]

Hello,
I'm new to FUSE as well as this crate. So, I'm probably missing something here and I would be thankful if you can just point me to the appropriate documentation or give me insights about whatever is it that I'm missing.

The issue is that unmounting (eg: calling SessionUnmounter.unmount or drop()-ing the BackgroundSession object) internally from the process which has mounted the filesystem seems to leave a dangling transport link on the mount point. How can I have the process clean up after itself properly?

FTR, I know that the dangling transport link can be removed if I called umount/fusermount3 on the mount point... but calling a new system binary just to remove the dangling endpoint seems rather dirty. I am hoping there is some function/method that would also remove the dangling transport endpoint when unmounting the filesystem.

My objective is that I would like to cleanly unmount the filesystem on either user executing umount/fusermount3 or user sending signals (eg: SIGTERM/INT). There doesn't seem to be any "listener" with which the controller program can identify if the filesystem has been unmounted externally. Thus, a thread spawned to handle user signals will stay blocked on a signal since it can't exactly know if the filesystem has been shutdown externally, leaving a dangling process. And, a shutdown triggered via signal leaves dangling transport link.

[dannycjones]

Hey @shreyanshk. I believe you're looking for the autounmount option: https://docs.rs/fuser/latest/fuser/enum.MountOption.html#variant.AutoUnmount

[shreyanshk]

Hello @dannycjones ,
I had it passed down to (spawn_ and) mount2 permanently in the mount options but it doesn't seem to be working reliably for me. I was able to reproduce this issue it reliably in the past but that know-how has escaped my mind at the moment.

I can try to recall and verify, if that helps.