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
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

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

Closed (moved)
Open
Opened Nov 12, 2018 by Trac@tracbot

systemd restart loop when tor@default.service::Type=notify

I'm experiencing a 300sec restart loop when Tor is run as a service. This is Debian stretch using systemd.

This is a system in which tor-0.3.4.8 was installed and running OK. Then I overrode the tor executable with a 0.3.5.4-alpha build (with configure --prefix=), and it started showing this problem.

I tried some workarounds found on the Net, such as changing the /var/run symlink from /run to ../run (which shouldn't need to be done), tweaking values of ReadWriteDirectories in tor@default.service, and changing TimeoutStartSec to 0. None of that worked.

What does work is setting Type=simple instead of notify, but then I came across ticket #11016 (moved) and really, notify should work. So if it doesn't, I wonder if this version of tor 0.3.5 alpha could have a fault? How can I look into that more closely to verify?

This is the log in syslog prior to restart:

systemd[1]: tor@default.service: Start operation timed out. Terminating.
systemd[1]: Failed to start Anonymizing overlay network for TCP.
systemd[1]: tor@default.service: Unit entered failed state.
systemd[1]: tor@default.service: Failed with result 'timeout'.
systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Anonymizing overlay network for TCP.
systemd[1]: Starting Anonymizing overlay network for TCP...

And here is my current tor@default.service:

[Unit]
Description=Anonymizing overlay network for TCP
After=network.target nss-lookup.target
PartOf=tor.service
ReloadPropagatedFrom=tor.service

[Service]
#Type=notify
Type=simple
NotifyAccess=all
PIDFile=/var/run/tor/tor.pid
PermissionsStartOnly=yes
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor
ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutStartSec=300
TimeoutStopSec=60
Restart=on-failure
LimitNOFILE=65536

# Hardening
AppArmorProfile=-system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH

Advice?

Trac:
Username: jchevali

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.3.5.x-final
Milestone
Tor: 0.3.5.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#28410