Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #21818

Closed (moved)
Open
Opened Mar 25, 2017 by cypherpunks@cypherpunks

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:

  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 (moved) gets rid of the privileged ports issue here, at least in some environs?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#21818