tor's handling of SIGHUP considered harmful
When I run systemctl reload tor tor says Received reload signal (hup). Reloading config and resetting internal state. and then, under many perfectly valid configurations, terminates. (As an aside, I wonder what does "resetting internal state" mean. It isn't closing circuits; what state is being reset?)
The "feature" of being able to reload the config at runtime is alluring, but it's a false promise because many configurations which are valid at startup are not valid after tor has already bound ports, dropped privs, and done whatever else it did at startup.
The scenario which caused me to file this was that i attempted to add a listener on a privileged port. After getting a person in another country to reboot the machine for me (it's only reachable via hidden service) my new configuration was fine, but, attempting to "reload" tor's config was an extremely inconvenient mistake for me because, having already dropped privs, tor was not allowed to bind the port (Permission denied).
See also #17873 (moved) for a similar but different scenario which led to the same problem.
I'm not sure what solution I'd prefer for this problem, but here are a few possibilities:
-
get rid of the runtime config reloading completely (easy, but lame)
-
try to fail gently when reloading the config (report errors to the log, but don't die. probably a lot more work for an incomplete solution.)
-
make SIGHUP cause tor to re-parse the config, report any errors it can, but not actually use the new config unless it contains a special new directive like
AllowRuntimeConfigChange 1(the documentation for which would of course discuss the myriad ways this could make tor exit). (this might be the best option?) -
maybe #8195 (moved) gets rid of the privileged ports issue here, at least in some environs?