Opened 7 months ago

Last modified 6 months ago

#25456 new enhancement

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

Reported by: isis Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: packaging, systemd, configuration, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor: Sponsor8-can

Description

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.

Child Tickets

Change History (3)

comment:1 Changed 6 months ago by nickm

Keywords: 034-triage-20180328 added

comment:2 Changed 6 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:3 Changed 6 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.