Page MenuHomePhabricator

systemd unit file for Tor package?
Closed, ResolvedPublic

Description

Do we need a systemd file for the Tor package?

Debian jessie's version of Tor still comes with a sysvinit script. Additionally we have deb.torproject.org enabled (through the anon-shared-build-apt-sources-tpo package). The latter my sooner or later include a systemd unit file by The Tor Project.

I am confused what we need qubes-whonix/blob/master/etc/systemd/system/qubes-whonix-tor.service for. Is it just fancy or is there a real need for?

If it was fancy, I don' think we should ship systemd files for packages that come from Debian or The Tor Project that are still sysvinit based. There is simply too many old systemd unit files, just check /etc/init.d. Shipping such as systemd unit file inside Whonix just seems wrong. Those should be contributed upstream. They have a much deeper understanding of the package and if they add new systemd unit files it will get more broader review and testing. Why not just rely on systemd's sysvinit script compatibility, that seems to work quite well for all the remaining stuff in /etc/init.d?

I feel very uncomfortable with Whonix shipping a systemd unit file for Tor if there is no strong reason to do so. As soon as upstream (Debian or The Tor Project) switches to systemd themselves, something during package upgrade could go wrong in conflict with Whonix's specifics. When upstream releases a package upgrade, their maintainer scripts run without knowing whatever Whonix has cooked up. In worst case the package manager will be broken and the Tor service will no longer automatically start during that transition. For all users. Support hell.

I know, there is currently an issue in Whonix 11. On first boot, the Tor service won't successfully start. That's a bug that has yet to be analyzed. Likely caused by Whonix's Tor config. Maybe a bug in Whonix's Tor config or Tor itself. That requires a fix or workaround. Anyhow, I don't think it's right to not find out what's going on and to simply add a systemd workaround while trading the risk of some day breaking Tor connection for all Whonix users.

Related:
T303

Details

Impact
Normal

Event Timeline

Patrick updated the task description. (Show Details)May 15 2015, 2:27 AM
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, nrgaway, HulaHoop.
Patrick created this task.
Patrick raised the priority of this task from to Normal.

+1

I'm not a fan of reinvented wheels either because of conflicts and the increased burden. You probably agree the same stance should be taken for other components like apparmor profiles whenever upstream incorporates theirs in Debian.

In T304#4499, @HulaHoop wrote:

You probably agree the same stance should be taken for other components like apparmor profiles whenever upstream incorporates theirs in Debian.

That might be a bigger off-topic discussion. Moved and answered here. Current status of AppArmor and Whonix:
https://www.whonix.org/forum/index.php/topic,97.msg8159.html#msg8159

The qubes-whonix-tor.service was implemented to solve the issue you were talking about where Tor would sometimes not start properly on boot.

This service file seems to be working and I have not had that issue since. I named it as such so as not to conflict with an official distribution unit file or even one provided by Whonix, which would be located in /etc/systems/system directory named tor.

The qubes-whonix-tor.service is designed to override both a official distribution and Whonix local unit files and can be updated or removed in future with a qubes-whonix update.

Since the upstream package version of Tor does not seem to be maintained very well and this solution works I submit it is required, at least for Qubes.

I am also working on a more hardened unit file for Tor as well https://github.com/nrgaway/qubes-whonix/blob/master/tests/wip/tor.service

One thing that seems to me missing from Tor upstream is sd_notify, so watchdog has been disabled, otherwise the service would be restarted every X seconds.

In T304#4517, @nrgaway wrote:

The qubes-whonix-tor.service was implemented to solve the issue you were talking about where Tor would sometimes not start properly on boot.

That was T251, which is now fixed. There is still a related issue T320, but that will soon be fixed also. (That issue is an upstream bug in Tor, isn't systemd related. Systemd would just be a bandage.)

I am also working on a more hardened unit file for Tor as well https://github.com/nrgaway/qubes-whonix/blob/master/tests/wip/tor.service

The should be suggested upstream. Adding flag x, y, etc. may seem simple, but can cause issues later. See stuff they discussed earlier. They added a systemd unit file to git:
https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in

They had a lot systemd related discussion and improvement already.

They seem interested and responsive.

Reported a bug upstream,
spaces in Tor's systemd unit file causes issues:
https://trac.torproject.org/projects/tor/ticket/16162

One thing that seems to me missing from Tor upstream is sd_notify, so watchdog has been disabled, otherwise the service would be restarted every X seconds.

Seems fixed upstream. https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in uses Type = notify.

Patrick changed the task status from Open to Review.May 23 2015, 4:50 PM

Doesn't look like we need one.

Patrick closed this task as Resolved.May 24 2015, 4:31 PM
Patrick claimed this task.

Works fine in Whonix 11.0.0.2.0-developers-only.