Should cgofuse unmount on SIGHUP? about cgofuse HOT 4 CLOSED

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.

from cgofuse.

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).

from cgofuse.

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

from cgofuse.

Thanks for the confirmation. Closing this.

from cgofuse.