Opened 20 months ago

Closed 3 weeks ago

#21818 closed defect (fixed)

tor's handling of SIGHUP considered harmful

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 035-roadmap-proposed
Cc: dmr, traumschule Actual Points:
Parent ID: #25510 Points:
Reviewer: Sponsor:

Description

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)
  1. 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.)
  1. 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?)
  1. maybe #8195 gets rid of the privileged ports issue here, at least in some environs?

Child Tickets

Change History (7)

comment:1 in reply to:  description Changed 18 months ago by teor

Parent ID: #17873

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.

comment:2 Changed 17 months ago by dgoulet

Milestone: Tor: unspecified

Missing milestone.

comment:3 Changed 7 months ago by teor

Parent ID: #17873#25510
Version: Tor: unspecified

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

comment:4 Changed 5 months ago by nickm

Keywords: 035-roadmap-proposed added

comment:5 Changed 3 months ago by dmr

Cc: dmr added

comment:6 Changed 2 months ago by traumschule

Cc: traumschule added

comment:7 in reply to:  description Changed 3 weeks ago by teor

Resolution: fixed
Status: newclosed

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

Replying to cypherpunks:

...

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

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

Note: See TracTickets for help on using tickets.