Opened 3 years ago

Closed 3 years ago

#19847 closed enhancement (wontfix)

make tor@default.service a non-static unit

Reported by: cypherpunks Owned by:
Priority: Medium Milestone:
Component: - Select a component Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Making it a non-static unit allows users to disable it via the usual systemctl command

systemctl disable tor@default.service

Are there any drawbacks to allowing that?

Child Tickets

Change History (6)

comment:1 Changed 3 years ago by weasel

Resolution: invalid
Status: newclosed

Unclear what is requested here.

comment:2 Changed 3 years ago by cypherpunks

Resolution: invalid
Status: closedreopened

Ok, let me elaborate:
Currently it is not possible to disable tor@default. service
via

systemctl disable tor@default

since it is a static unit.

Making it a non-static unit would allow users to disable the default instance while continuing to use other multi-instances.

This is just about whether it is ok to add an [Install] section to the unit file or not.

More on static vs. non-static units:
https://bbs.archlinux.org/viewtopic.php?id=147964

context:
https://lists.torproject.org/pipermail/tor-relays/2016-August/009851.html

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:3 Changed 3 years ago by weasel

If static means it has an [install] section, then we don't want that.

We want tor.service to pull it in. This means that tor.service restart will restart all the instances.

Also, tor.service will not include the default tor service if it doesn't have a config file.

comment:4 in reply to:  3 Changed 3 years ago by cypherpunks

Replying to weasel:

If static means it has an [install] section, then we don't want that.

We want tor.service to pull it in. This means that tor.service restart will restart all the instances.

If you add an [Install] section, the restart effect stays the same.
Or explained the other way around: /lib/systemd/system/tor@.service has an [Install] section and they also get restarted when tor.service is restarted (because of the PartOf= line I assume).

What is the current rational for not having a [Install] section in tor@default?

thank you!

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:5 Changed 3 years ago by cypherpunks

also: I stumbled on https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor-generator

line 21 suggests that the author does not expect tor@default. service to be static. Line 21 has no effect because tor@default. service is started even if there is no link present because it is static after all.

[ -e "/etc/tor/torrc" ] && ln -s "$DEFAULTTOR" "$WANTDIR/"
Last edited 3 years ago by cypherpunks (previous) (diff)

comment:6 Changed 3 years ago by weasel

Resolution: wontfix
Status: reopenedclosed

The default service should get started with tor.service. The generator takes care to pull in all the tor instances on the system, default or not.

If you don't want the default instance started, mask it or cause the generator to not pick it up. I do not think that installing the default instance into /etc/systemd/system/multi-user.target.wants is what I want here.

Note: See TracTickets for help on using tickets.