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
  • #25456

Closed (moved)
Open
Opened Mar 09, 2018 by Isis Lovecruft@isis

tor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernate

I very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that there experience is the same. Humans doing things computers can do is bad UX. I propose, at the very least, on *nix systems that we modify the systemd .service file(s) we already distribute to do this for the human. (We should also figure out some equivalent for MacOS, Windows, and mobile, if possible, but those can be separate tickets.)

From reading this question that femme linked me to, it looks like the way to do it is either a script which gets installed into /lib/systemd/system-sleep/, or a second .service file that is wanted by suspend.target. I'm not sure which is cleaner? I would assume the .service file approach is cleaner, because then it can be selectively enabled/disabled by the human more easily.

To upload designs, you'll need to enable LFS and have an 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#25456