Should cgofuse unmount on SIGHUP?

[billziss-gh]

Cgofuse currently automatically unmounts on SIGINT, SIGTERM and SIGHUP (on UNIX). I notice that rclone allows the user to send it the SIGHUP signal.

From rclone:

Alternatively, you can send a ` + "`SIGHUP`" + ` signal to rclone for
it to flush all directory caches, regardless of how old they are.
Assuming only one rclone instance is running, you can reset the cache
like this:
    kill -SIGHUP $(pidof rclone)

Under cgofuse this would result in rclone mount being terminated. Any thoughts?

Ping @ncw.

[ncw]

The reason for the signal handlers was to abstract the differences between WinFsp and libfuse.

WinFsp unmounts on the windows equivalent of SIGINT I think, so using SIGINT (ctrl-C at the terminal) and SIGTERM (kill $pid) seem sensible.

I think many unix programs use SIGHUP for other things (eg reload the config) so I think cgofuse shouldn't trap that.

You might want to include SIGQUIT (ctrl-\ from most keyboards) also, though SIGQUIT does something special with go programs and that is produce a backtrace of all running goroutines before killing it.

[billziss-gh]

I modified cgofuse to not catch SIGHUP.

I am less certain about catching SIGQUIT. According to Changing the behavior of signals in Go programs:

Notify disables the default behavior for a given set of asynchronous signals and instead delivers them over one or more registered channels. Specifically, it applies to the signals SIGHUP, SIGINT, SIGQUIT, SIGABRT, and SIGTERM.

So this would mean that catching SIGQUIT would disable the default Go behavior for this signal, which would probably be frowned upon by Go programmers that rely on the default behavior (getting Go stacktraces).

[ncw]

That seems like a sensible plan to leave out SIGQUIT. SIGTERM and SIGINT are by far the most popular signals anyway.

[billziss-gh]

Thanks for the confirmation. Closing this.