Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:29:16Zhttps://gitlab.torproject.org/legacy/trac/-/issues/8908Tor systemd socket activation support2020-06-13T14:29:16ZcypherpunksTor systemd socket activation supportAllow Tor to be started on-demand on Linux under systemd.
WIP patch posted here: https://lists.torproject.org/pipermail/tor-dev/2013-May/004885.html
More info about socket activation: http://0pointer.de/blog/projects/socket-activation....Allow Tor to be started on-demand on Linux under systemd.
WIP patch posted here: https://lists.torproject.org/pipermail/tor-dev/2013-May/004885.html
More info about socket activation: http://0pointer.de/blog/projects/socket-activation.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9807Add systemd service file for openSUSE2020-06-13T14:32:12ZTracAdd systemd service file for openSUSEHi all,
I have written a systemd service file for openSUSE. I have tested it with all currently supported versions (12.1, 12.2 and 12.3). Maybe it can be added in Tor's contrib/suse directory?
Thanks
**Trac**:
**Username**: microchipHi all,
I have written a systemd service file for openSUSE. I have tested it with all currently supported versions (12.1, 12.2 and 12.3). Maybe it can be added in Tor's contrib/suse directory?
Thanks
**Trac**:
**Username**: microchipTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12730systemd unit file could use --verify-config in ExecStartPre2020-06-13T14:37:41Zintrigerisystemd unit file could use --verify-config in ExecStartPreThe ExecStartPre directive (systemd.service(5)) allows to run commands before actually starting the service, and to _not_ start the service if one of these commands fail. It allows one to replicate the behavior that the tor initscript in...The ExecStartPre directive (systemd.service(5)) allows to run commands before actually starting the service, and to _not_ start the service if one of these commands fail. It allows one to replicate the behavior that the tor initscript in Debian has, which is desirable IMO: if we don't have this, then when we install the systemd unit file in Debian, we have a regression.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12731systemd unit file should explicitly pass --RunAsDaemon 02020-06-13T14:37:41Zintrigerisystemd unit file should explicitly pass --RunAsDaemon 0The current systemd unit uses "Type = simple", so systemd does not expect tor to fork. If the user has "RunAsDaemon 1" in their torrc, then things won't work as expected. This is e.g. the case on Debian (and derivatives), since there we ...The current systemd unit uses "Type = simple", so systemd does not expect tor to fork. If the user has "RunAsDaemon 1" in their torrc, then things won't work as expected. This is e.g. the case on Debian (and derivatives), since there we pass "--defaults-torrc /usr/share/tor/tor-service-defaults-torrc" (that contains "RunAsDaemon 1") by default.
The only solution I can see to this problem is to explicitly pass "--RunAsDaemon 0" when starting tor from the systemd unit file.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12939Add NoNewPrivileges=true to systemd unit.2020-06-13T14:38:04ZTracAdd NoNewPrivileges=true to systemd unit.Please consider adding NoNewPrivliges=true to the systemd unit. This will prevent tor from gaining privileges (e.g. by executing setuid binaries).
**Trac**:
**Username**: stebalienPlease consider adding NoNewPrivliges=true to the systemd unit. This will prevent tor from gaining privileges (e.g. by executing setuid binaries).
**Trac**:
**Username**: stebalienTor: 0.2.6.x-finalintrigeriintrigerihttps://gitlab.torproject.org/legacy/trac/-/issues/13196systemd unit file needs to make /var/run/tor writable2020-06-13T14:38:51Zintrigerisystemd unit file needs to make /var/run/tor writableThe changes introduced for #12751 break the unit file with systemd v215, as they prevent /var/run/tor/ from being writable. I'll test and submit a patch that resolves this shortly.The changes introduced for #12751 break the unit file with systemd v215, as they prevent /var/run/tor/ from being writable. I'll test and submit a patch that resolves this shortly.intrigeriintrigerihttps://gitlab.torproject.org/legacy/trac/-/issues/12751systemd unit file could use more filesystem namespace hardening options2020-06-13T14:38:51Zintrigerisystemd unit file could use more filesystem namespace hardening optionssystemd has nice features to restrict what part of the filesystem a service has read-only or read-write access to (ReadOnlyDirectories, ReadWriteDirectories) that we could use. Also InaccessibleDirectories could be made a bit more restri...systemd has nice features to restrict what part of the filesystem a service has read-only or read-write access to (ReadOnlyDirectories, ReadWriteDirectories) that we could use. Also InaccessibleDirectories could be made a bit more restrictive.Tor: 0.2.6.x-finalintrigeriintrigerihttps://gitlab.torproject.org/legacy/trac/-/issues/8368Add tor.service (for systemd) to upstream package2020-06-13T14:40:29ZTracAdd tor.service (for systemd) to upstream packageIn Fedora we have a custom systemd service file for running Tor. We are encouraged to push changes upstream, and thus I am proposing that it be included as part of the upstream tarball. I have pasted the contents below, but please do adv...In Fedora we have a custom systemd service file for running Tor. We are encouraged to push changes upstream, and thus I am proposing that it be included as part of the upstream tarball. I have pasted the contents below, but please do advise on whether this can be improved:
$ cat tor.service
[Unit]
Description = Anonymizing overlay network for TCP
After = syslog.target network.target nss-lookup.target
[Service]
Type = simple
ExecStart = /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --quiet
ExecReload = /bin/kill -HUP ${MAINPID}
ExecStop = /bin/kill -INT ${MAINPID}
TimeoutSec = 30
Restart = on-failure
LimitNOFILE = 4096
[Install]
WantedBy = multi-user.target
**Trac**:
**Username**: jamielinuxTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14141enhancments and fixes for systemd support2020-06-13T14:41:38ZTracenhancments and fixes for systemd supportThe following patch series contains:
1) fix unit & code to work with both RunAsDaemon = 0 or 1
2) improve information about state presented to administrator
3) fix and enable watchdog support
Detailed descriptions inside each patch.
...The following patch series contains:
1) fix unit & code to work with both RunAsDaemon = 0 or 1
2) improve information about state presented to administrator
3) fix and enable watchdog support
Detailed descriptions inside each patch.
**Trac**:
**Username**: tomek@pipebreaker.plTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13805Improve hardening in tor.service2020-06-13T14:44:34ZTracImprove hardening in tor.serviceI suggest that tor.service's hardening implementation be changed. These lines would be replaced:
```
[Service]
DeviceAllow = /dev/null rw
DeviceAllow = /dev/urandom r
InaccessibleDirectories = /home
ReadOnlyDirectories = /
ReadWriteDirec...I suggest that tor.service's hardening implementation be changed. These lines would be replaced:
```
[Service]
DeviceAllow = /dev/null rw
DeviceAllow = /dev/urandom r
InaccessibleDirectories = /home
ReadOnlyDirectories = /
ReadWriteDirectories = /var/lib/tor
ReadWriteDirectories = /var/log/tor
ReadWriteDirectories = /var/run/tor
ReadWriteDirectories = /proc
```
With these lines:
```
PrivateDevices = yes
ProtectHome = yes
ProtectSystem = full
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID
```
Using PrivateDevices instead of DeviceAllow's is more secure as it create a totally separate /dev as well as removing the CAP_MKNOD capability.
ProtectHome makes /home inaccessible, equivalent to "InaccessibleDirectories = /home" but (arguably) more comprehensible.
ProtectSystem=full make /usr and /etc read only.
CapabilityBoundingSet reduces the process capability to just what it needs.
See http://www.freedesktop.org/software/systemd/man/systemd.exec.html
This discussion was started at https://bugs.gentoo.org/show_bug.cgi?id=529212 and the suggestion to use the higher level constructs was made by the Gentoo systemd team.
For historical reference, tor.service was added in #8368
**Trac**:
**Username**: candrewsTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16162spaces in Tor's systemd unit file causes issues2020-06-13T14:46:28Zproperspaces in Tor's systemd unit file causes issueshttps://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in is currently using spaces.
I recommend not doing this. Causes issues. Info on the issue...
`deb-systemd-helper fails to enable systemd units when using 'WantedBy = ...https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in is currently using spaces.
I recommend not doing this. Causes issues. Info on the issue...
`deb-systemd-helper fails to enable systemd units when using 'WantedBy = ' with spaces`:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786418
More reasoning why this is syntactically incorrect:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786421Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16398systemd startup timeout on v0.2.6.9 (git-145b2587d1269af4)2020-06-13T14:47:01ZTracsystemd startup timeout on v0.2.6.9 (git-145b2587d1269af4)I'm using experimental builds on Ubuntu 15.04. Since the last update systemd is looping forever in restarting Tor, because it detects a start timeout:
```
Jun 18 12:26:27 dharma systemd[1]: Starting Anonymizing overlay network for TCP.....I'm using experimental builds on Ubuntu 15.04. Since the last update systemd is looping forever in restarting Tor, because it detects a start timeout:
```
Jun 18 12:26:27 dharma systemd[1]: Starting Anonymizing overlay network for TCP...
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:26:27 dharma tor[11487]: Configuration was valid
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.400 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.400 [notice] Opening Control listener on /var/run/tor/control
Jun 18 12:27:12 dharma systemd[1]: tor.service start operation timed out. Terminating.
Jun 18 12:27:12 dharma systemd[1]: Failed to start Anonymizing overlay network for TCP.
Jun 18 12:27:12 dharma systemd[1]: Unit tor.service entered failed state.
Jun 18 12:27:12 dharma systemd[1]: tor.service failed.
Jun 18 12:27:12 dharma systemd[1]: tor.service holdoff time over, scheduling restart.
Jun 18 12:27:12 dharma systemd[1]: Starting Anonymizing overlay network for TCP...
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:27:12 dharma tor[11572]: Configuration was valid
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.875 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.882 [notice] Opening Control listener on /var/run/tor/control
```
... and goes on like this forever. This wasn't happening until few days ago, where this last update was distirbuted.
**Trac**:
**Username**: maxxerhttps://gitlab.torproject.org/legacy/trac/-/issues/16782systemd unit file is not compatible with the AppArmorProfile= directive2020-06-13T14:47:58Zintrigerisystemd unit file is not compatible with the AppArmorProfile= directiveIf I add the `AppArmorProfile=system_tor` directive to the unit file on current Debian sid, tor doesn't start and I get:
`tor.service: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system`
As discussed on the systemd ma...If I add the `AppArmorProfile=system_tor` directive to the unit file on current Debian sid, tor doesn't start and I get:
`tor.service: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system`
As discussed on the systemd mailing-list last year (http://lists.freedesktop.org/archives/systemd-devel/2014-October/023909.html), setting up AppArmor confinement requires /proc to be writable.
And indeed, adding `ReadWriteDirectories=-/proc` fixes this problem for me. I intend to ask weasel to enable the AppArmor profile back in Debian (which we lost when migrating to systemd), so my question is: do you want `ReadWriteDirectories=-/proc` upstream (as a way to ease the work for downstreams who want to enable AppArmor confinement), or should we add it to the Debian delta?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18294systemd AppArmorProfile= directive unavailable leads to not loading AppArmor ...2020-06-13T14:54:14Zadrelanossystemd AppArmorProfile= directive unavailable leads to not loading AppArmor profile on Debian jessieTor version: 0.2.7.6-1~d80.jessie+1
Tor version installed from: deb.torproject.org
`/lib/systemd/system/tor@default.service` uses `AppArmorProfile=system_tor`.
Debian jessie's (currently: Debian stable) version of systemd was compiled ...Tor version: 0.2.7.6-1~d80.jessie+1
Tor version installed from: deb.torproject.org
`/lib/systemd/system/tor@default.service` uses `AppArmorProfile=system_tor`.
Debian jessie's (currently: Debian stable) version of systemd was compiled without AppArmor support.
(The systemd version that is available from Debian stretch (currently: Debian testing) has systemd >= 217 has AppArmor support.)
Source:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760526
Therefore the AppArmor profile will not be load.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18356obfs4proxy cannot bind to <1024 port with systemd hardened service unit2020-06-13T14:54:36ZTracobfs4proxy cannot bind to <1024 port with systemd hardened service unitHi,
I was running an obfs4proxy Debian Wheezy bridge with such configuration in torrc:
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443 any more, while tor l...Hi,
I was running an obfs4proxy Debian Wheezy bridge with such configuration in torrc:
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443 any more, while tor logs had such messages:
```
Feb 21 22:51:09.000 [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied)
Feb 21 22:51:09.000 [warn] Managed proxy at '/usr/bin/obfs4proxy' failed the configuration protocol and will be destroyed.
```
Mind that I have already set the appropriate capability to the obfs4proxy binary:
```
getcap /usr/bin/obfs4proxy
/usr/bin/obfs4proxy = cap_net_bind_service+ep
```
I took some time moving things around and I think the problem resides on the systemd service unit: https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in and specifically the option introduced in b4170421cc58d8c57254f4224ba259e817f48869 .
```
NoNewPrivileges=yes
```
I assume so because flipping 'NoNewPrivileges=no' results in obfs4proxy binding to 443. Also, 'PR_SET_NO_NEW_PRIVS' section in 'man 2 prctl' implies so:
```
PR_SET_NO_NEW_PRIVS (since Linux 3.5)
Set the calling process's no_new_privs bit to the value in arg2. With
no_new_privs set to 1, execve(2) promises not to grant privileges to do
anything that could not have been done without the execve(2) call (for
example, rendering the set-user-ID and set-group-ID permission bits, and
file capabilities non-functional). Once set, this bit cannot be unset.
The setting of this bit is inherited by children created by fork(2) and
clone(2), and preserved across execve(2).
For more information, see the kernel source file Documenta‐
tion/prctl/no_new_privs.txt.
```
I understand that 'NoNewPrivileges=no' is a system security drawback but I also consider a regression to not be able to bind obfs4proxy to ports <1024. Could we find a middle ground?
If that helps, I'm running:
```
tor: 0.2.7.6-1~d80.jessie+1
deb.torproject.org/torproject.org/ jessie/main amd64 Packages
obfs4proxy: 0.0.4-1~tpo1
deb.torproject.org/torproject.org/ obfs4proxy/main amd64 Packages
```
Also:
```
cat /etc/debian_version
8.3
cat /proc/version
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
```
Thanks for your work.
**Trac**:
**Username**: irregulatorTor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/22094Creating private_key/hostname fails with "RO filesystem" message but target d...2020-06-13T15:08:16ZTracCreating private_key/hostname fails with "RO filesystem" message but target dir is actually RWVersion: 0.2.9.10 (git-e28303bcf90b842d) on debian jessie live iso
## Problem
```
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr...Version: 0.2.9.10 (git-e28303bcf90b842d) on debian jessie live iso
## Problem
```
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr 28 10:22:58.000 [err] Couldn't write generated key to "/var/tor/hidden_site/private_key".
```
## Wanted behaviour
These files are to be written in a directory which *IS* writable by the designated running user
These error/warning message seem wrong, and the creating of the hidden service is rendered impossible, if running through systemd
## Steps to reproduce
1) run debian-live-8.7.1-amd64-standard.iso is live mode
2) run following commands
```
gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
cat << "EOF" | sudo tee /etc/apt/sources.list.d/tor.list
deb http://deb.torproject.org/torproject.org jessie main
deb-src http://deb.torproject.org/torproject.org jessie main
EOF
sudo apt-get update
sudo apt-get install deb.torproject.org-keyring
sudo apt-get install tor
sudo systemctl stop tor
sudo mkdir -p /var/tor
sudo mount -t tmpfs tmpfs /var/tor/
sudo mkdir -p /var/tor/hidden_site
sudo chmod 700 /var/tor/hidden_site
sudo chown debian-tor:debian-tor /var/tor/hidden_site
cat << "EOF" | sudo tee /etc/tor/torrc
HiddenServiceDir /var/tor/hidden_site
HiddenServicePort 80 127.0.0.1:8080
EOF
sudo -u debian-tor tor --verify-config
sudo systemctl start tor
```
NOTE: mounting a tmpfs is just an attempt at making sure no RO filesystem was in the game...
3) tor log
```
Apr 28 10:22:58.000 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) opening log file.
Apr 28 10:22:58.067 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 10:22:58.067 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 10:22:58.067 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 10:22:58.067 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 10:22:58.071 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr 28 10:22:58.000 [err] Couldn't write generated key to "/var/tor/hidden_site/private_key".
Apr 28 10:22:58.000 [warn] Error loading rendezvous service keys
Apr 28 10:22:58.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.9.10 )
```
## Actual mountpoints
```
aufs on / type aufs (rw,noatime,si=2cb2b7e036b24d5d,noxino)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=10240k,nr_inodes=124323,mode=755)
/dev/sr0 on /lib/live/mount/medium type iso9660 (ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,noatime,mode=755)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs (ro,noatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=204864k,mode=755)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /var/tor type tmpfs (rw,relatime)
```
## Manual run
If instead of running tor via systemctl, we then launch it manually in shell through ssh :
```
sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
```
`ps auxf` confirms it runs as `debian-tor`.
Here everything goes fine :
```
Apr 28 13:00:41.281 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 13:00:41.281 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 13:00:41.281 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 13:00:41.282 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 13:00:41.286 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 13:00:41.000 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) opening log file.
Apr 28 13:00:41.281 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 13:00:41.281 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 13:00:41.281 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 13:00:41.282 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 13:00:41.286 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 13:00:41.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Apr 28 13:00:41.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Apr 28 13:00:41.000 [notice] Bootstrapped 0%: Starting
Apr 28 13:00:41.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Apr 28 13:00:42.000 [notice] Opening Socks listener on /var/run/tor/socks
Apr 28 13:00:42.000 [notice] Opening Control listener on /var/run/tor/control
Apr 28 13:00:42.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 28 13:00:42.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 28 13:00:43.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 28 13:00:43.000 [notice] Bootstrapped 100%: Done
```
The hidden service files are created :
```
sudo find /var/tor -ls
31802 0 drwxrwxrwt 3 root root 60 Apr 28 12:30 /var/tor
31841 0 drwx------ 2 debian-tor debian-tor 80 Apr 28 13:00 /var/tor/hidden_site
36795 4 -rw------- 1 debian-tor debian-tor 23 Apr 28 13:00 /var/tor/hidden_site/hostname
36794 4 -rw------- 1 debian-tor debian-tor 887 Apr 28 13:00 /var/tor/hidden_site/private_key
```
**Trac**:
**Username**: nipilTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24577Systemctl tor.service invalid - Tor does not restart on systemctl start tor c...2020-06-13T15:18:41ZTracSystemctl tor.service invalid - Tor does not restart on systemctl start tor commandPlease refer to: https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04/903341
When I looked at tor.service I find it's nothing more than a dummy file that only returns true if the tor.service is...Please refer to: https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04/903341
When I looked at tor.service I find it's nothing more than a dummy file that only returns true if the tor.service is running and not the actual tor program itself:
----
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=Anonymizing overlay network for TCP (multi-instance-master)
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
----
So regardless if the TOR process is actually running or not, tor.service always returns TRUE. This is Invalid. and As a result running: sudo systemctl start|stop tor does nothing as you can see here:
● tor.service - Anonymizing overlay network for TCP (multi-instance-master)
** Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled)**
Active: active (exited) since Sun 2017-12-10 14:24:42 EST; 9min ago
Main PID: 17641 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/tor.service
So for the moment the temporary fix is:
Removing or renaming offending file /lib/systemd/system/tor.service and reloading the scripts w/ systemctl daemon-reload. because the actual and correct script to start tor is in /etc/init.d/tor
After this modifcation the resulting output of sudo systemctl status tor:
● tor.service - LSB: Starts The Onion Router daemon processes
** Loaded: loaded (/etc/init.d/tor; bad; vendor preset: enabled)**
Active: active (exited) since Sun 2017-12-10 14:24:42 EST; 26min ago
Docs: !man:systemd-sysv-generator(8)
Main PID: 17641 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/tor.service
I believe the tor script in /etc/init.d/tor is incorrectly attempting to start/stop tor through tor.service as well.
Please correct this as soon as possible thank you !
**Trac**:
**Username**: d3m0nkingxTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24715Job for tor.service failed when /var/run is tmpfs2020-06-13T15:19:23ZTracJob for tor.service failed when /var/run is tmpfsISSUE SUMMARY
=============
For this test I'm running Tor 0.3.2.6-alpha (git-87012d076ef58bb9) on Gentoo Linux. On my system, the /var/run/tor directory does not exist, and /var/run is a link to /run which is mounted as tmpfs:
tmpf...ISSUE SUMMARY
=============
For this test I'm running Tor 0.3.2.6-alpha (git-87012d076ef58bb9) on Gentoo Linux. On my system, the /var/run/tor directory does not exist, and /var/run is a link to /run which is mounted as tmpfs:
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
Attempting to start tor using tor.service fails:
vilhelm@sophia ~ $ sudo systemctl restart tor
Job for tor.service failed because the control process exited with error code.
See "systemctl status tor.service" and "journalctl -xe" for details.
vilhelm@sophia ~ $ sudo systemctl status tor.service
● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-12-06 09:08:19 EST; 4s ago
Process: 12244 ExecStart=/usr/bin/tor -f /etc/tor/torrc (code=exited, status=1/FAILURE)
Process: 12243 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
Main PID: 12244 (code=exited, status=1/FAILURE)
Dec 06 09:08:19 sophia systemd[1]: tor.service: Service hold-off time over, scheduling restart.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Dec 06 09:08:19 sophia systemd[1]: Stopped Anonymizing overlay network for TCP.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Start request repeated too quickly.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
vilhelm@sophia ~ $ sudo journalctl -xe
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has begun starting up.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.596 [notice] Read configuration file "/etc/tor/torrc".
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.597 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:18 sophia tor[12243]: Configuration was valid
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Read configuration file "/etc/tor/torrc".
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Scheduler type KIST has been enabled.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Opening OR listener on 0.0.0.0:443
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Opening Extended OR listener on 127.0.0.1:0
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Extended OR listener listening on port 35193.
Dec 06 09:08:19 sophia Tor[12244]: Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:19 sophia Tor[12244]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:19 sophia Tor[12244]: This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:19 sophia Tor[12244]: Read configuration file "/etc/tor/torrc".
Dec 06 09:08:19 sophia Tor[12244]: Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:19 sophia Tor[12244]: Scheduler type KIST has been enabled.
Dec 06 09:08:19 sophia Tor[12244]: Opening OR listener on 0.0.0.0:443
Dec 06 09:08:19 sophia Tor[12244]: Opening Extended OR listener on 127.0.0.1:0
Dec 06 09:08:19 sophia Tor[12244]: Extended OR listener listening on port 35193.
Dec 06 09:08:19 sophia Tor[12244]: Unable to open "/var/run/tor/tor.pid" for writing: No such file or directory
Dec 06 09:08:19 sophia Tor[12244]: Unable to write PIDFile "/var/run/tor/tor.pid"
Dec 06 09:08:19 sophia Tor[12244]: set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
Dec 06 09:08:19 sophia systemd[1]: tor.service: Main process exited, code=exited, status=1/FAILURE
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has failed.
--
-- The result is RESULT.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Service hold-off time over, scheduling restart.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Dec 06 09:08:19 sophia systemd[1]: Stopped Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has finished shutting down
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has finished shutting down.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Start request repeated too quickly.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has failed.
--
-- The result is RESULT.
SUSPECTED CAUSE
===============
The issue appears to result from the missing /var/run/tor directory and a lack of write permission to create the /var/run/tor/tor.pid PIDFile. I can manually create a /var/run/tor directory, but it will be gone if the system restarts since /var/run is tmpfs. The /var/run/tor directory and appropriate permissions should be configured in the tor.service file by default.
PROPOSED SOLUTION
=================
If I add the following lines to the /lib64/systemd/system/tor.service file the issue is resolved:
Group=tor
RuntimeDirectory=tor
RuntimeDirectoryMode=0770
I suggest adding these lines to the Tor source code contrib/dist/tor.service.in file so that the installed tor.service file will have the configuration lines to automatically create a /var/run/tor directory with the necessary permissions.
**Trac**:
**Username**: vilhelmgrayTor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25182systemd unit file starts Tor before IPv6 address is available2020-06-13T15:21:46ZSteven Murdochsystemd unit file starts Tor before IPv6 address is availableOn Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address a...On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.
As a work-around I copied `/lib/systemd/system/tor*` to `/etc/systemd/system/` and added `RestartSec=10` to the `[Service]` section of `tor@default.service` and `tor@.service`. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.
See log file below.
```
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25456tor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernate2020-06-13T15:22:51ZIsis Lovecrufttor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernateI 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 ...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](https://askubuntu.com/questions/661715/make-a-script-start-after-suspend-in-ubuntu-15-04-systemd/661747#661747) 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.Tor: unspecified