Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 313
    • Issues 313
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 34
    • Merge requests 34
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #2302
Closed
Open
Created Dec 19, 2010 by Damian Johnson@atagar

Controller event for sighup and shutdown

A while back Nick and I discussed adding a controller event for sighups. This isn't something that I'll be getting to any time soon but, it would be a nice addition at some point.

10:15 < nickm> atagar: answering on the ticket. thanks for the poke 10:23 < nickm> there 10:25 < atagar> thx 10:25 < nickm> BTW, are there a lot of log messages that arm parses? 10:26 < nickm> Are some of them things that should turn into events of some kind? 10:28 < atagar> arm tracks NOTICE events for sighup/shutdown, NEWDESC/NS/NEWCONSENSUS to updated cached results, and BW as a heartbeat 10:28 < nickm> So one of these things is not like the others 10:29 < nickm> The content of BW and NEWDESC/NS/NEWCONSENSUS are explicitly defined parts of the API. 10:30 < nickm> NOTICE stuff is just log messages, and not guaranteed to have any particular format. 10:30 < atagar> yup 10:30 < nickm> So probably we should have an event for "we got a signal" or "we're shutting down" 10:30 < nickm> Those both do sound like STATUS_GENERAL events 10:31 < nickm> If we don't have STATUS events for those already, we should 10:31 < atagar> hmm, I haven't checked - I'll look into it when adding the 'conf changed' event type 10:32 < nickm> maybe write up what the event should look like before you start hacking ? 10:32 < atagar> Are you thinking a proposal? It would be kinda short... 10:33 < nickm> If you want. It could also just be in the form of writing the patch to control-spec.txt before you write the code 10:33 < special> +1 on a control event for signals, especially HUP. 10:36 < nickm> That one should be trivial; just add the right call to signal_callback in main.c. You probably don't want to report signals that Tor ignores, and you'll want to convert signals to names, but other than that, it cake. 10:37 < nickm> shutting down is a little more complicated, since there are a couple of ways to do it 10:37 < nickm> oh, and we'll probably want a way to special-case trying to flush the controller connection if we're about to shut down. 10:39 < nickm> Hm. The way we do that now won't work right with bufferevents. One More Thing To Fix. :p

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking