On 09/09/2010 10:40 AM, Ulrik Mikaelsson wrote:
>> But as I mentioned segfault is just one of the examples. You can catch
>> SIGSEGV (which I'm assuming is what you guys meant by "segfault hook") but
>> I'd rather leave the default behavior, and you cannot catch SIGKILL in which
>> case things won't be cleaned up.
> SIGKILL, to my knowledge is normally only sent explicitly by the user,
> or automatically by the OOM-killer.
Or by a watchdog (ie most RT apps have watchdogs).
> In either case, when you start
> -9:ing things, all bets are off already. (It might as well be sent to
Not all bets are not off. Most things are cleaned up properly. For
example, if I have a TUN device open, when the process dies TUN device
goes away and all the routing entries are cleaned up. Which is basically
what I want from FUSE.
And yes, you're right about 'fusermount' getting -9 itself. I guess I'd
be ok if that one bet was off :).
> In the "fuser-mount waits for termination"-case, I don't think that
> would work for filesystems not explicitly started through fusermount,
> would it?
Hmm, from looking at the code I got an impression that FUSE init code
always calls fusermount.
> Is there any particular reason why the kernel can't be expected to
> clean up the mount once the pid that drove the FS disappears? AFAIU
> there is no way another PID can come along and resume the FS?
That'd be ideal. I don't know if this is doable and how hard.
I was hoping somebody on this list does, hence the question whether
changing fusermount is the best way to do the cleanup.