The MFS root state isn't saved if the daemon is stopped with Ctrl+C

[schomatis]

Following a series of (maybe not bugs but at least) some unusual behaviors I've found that Ctrl+Cing the daemon causes the MFS root's Close method (in teardown) to silently fail and thus causing any un-flushed files to be lost. Since the ipfs files command has the --flush option set by default this may not have had serious repercussions.

The Close error was (silently) failing because, when flushing, the DAG.Add operation was failing with blockservice is closed that was actually a hard-coded error (which threw me off substantially) shadowing any general HasBlock errors in the exchange service, i.e., Bitswap.

The real error was bitswap is closed generated in receiveBlockFrom that detected that the process was on its way to shutting down. This process was tied to the context that created the Bitswap interface, which actually seems to be derived from the original context that started the daemon that is closed when signaling the interrupt generated by Ctrl+C,

https://github.com/ipfs/go-ipfs/blob/c17aaa6e26512b6bbd0f60c0c39c82daacfba9e1/cmd/ipfs/main.go#L396-L409

This doesn't seem to happen with the ipfs shutdown command which more gracefully issues a Process().Close() without canceling the root context.

[Stebalien]

Hello: #4623

Would ignoring this error be enough?

[schomatis]

Would ignoring this error be enough?

I guess so (I'll test it a bit) but the bigger issue I think is that we're not honoring the teardown order

https://github.com/ipfs/go-ipfs/blob/c17aaa6e26512b6bbd0f60c0c39c82daacfba9e1/core/core.go#L668-L676

so any other service inter-dependency we rely on in the future will be subjected to a similar problem.

[Stebalien]

I see. Yeah, we really need a proper service management system (#5810). Regardless, we shouldn't be using context for closing processes.