tor's handling of SIGHUP considered harmful

[cypherpunks]

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 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:

1. get rid of the runtime config reloading completely (easy, but lame)

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

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

4. maybe #8195 gets rid of the privileged ports issue here, at least in some environs?

[teor]

Replying to cypherpunks:

...

1. get rid of the runtime config reloading completely (easy, but lame)

Try __ReloadTorrcOnSIGHUP 0 to make this happen.

Otherwise, this appears to be an instance of #17873.

[dgoulet]

Missing milestone.

[teor]

This ticket is relevant to mobile embedding, and is more likely to get fixed there.

[teor]

Now that #8195 and #17873 are closed, it looks like the remaining options for this ticket are:

Replying to cypherpunks:

...

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

If there are specific reload bugs that can be fixed, please open tickets for them. But in general, some users rely on tor exiting when the config is bad.

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

We won't change the default for __ReloadTorrcOnSIGHUP, because some users rely on tor exiting when the config is bad.