Description of problem: I have configured tor as a bridge relay, and when I boot my computer, it fails to start automatically. This is what I see: # systemctl status tor.service tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled) Active: failed (Result: start-limit) since Fri 2013-06-14 07:19:38 CEST; 3h 24min ago Process: 2720 ExecStop=/bin/kill -INT ${MAINPID} (code=killed, signal=INT) Process: 2714 ExecStart=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --quiet (code=exited, status=255) Jun 14 07:19:38 foo.example.com systemd[1]: tor.service start request repeated too quickly, refusing to start. Jun 14 07:19:38 foo.example.com systemd[1]: Failed to start Anonymizing overlay network for TCP. If later, I do systemctl start tor.service, it starts ok. Maybe is it something about the network is not ready while booting up? I have configured it to listen in IPv4 and IPv6 Version-Release number of selected component (if applicable): tor-0.2.3.25-1802.fc18.x86_64 systemd-201-2.fc18.7.x86_64 How reproducible: In my system, when I reboot, it doesn't start Steps to Reproduce: 1. systemctl enable tor.service 2. reboot 3. systemctl status tor.service Actual results: Tor doesn't start Expected results: Tor has started Additional info: I have configured a IPv6 ORPort, when I have the system at hand, I will remove that config and test ORPort 9001 ORPort [2001:db8::1]:9001
It seems it is the IPv6 ORPort. Anyway, I don't understand why this fails, maybe the IPv6 address gets up slower. I have enabled NetworkManager-wait-online.service, but it continues to fail at boot.
Thanks for reporting. Could you try disabling SELinux with selinux=0 in GRUB kernel config and then try again?
Use "getenforce 0" to temporarilly disable linux without needing a reboot or grub change. (and cause a long relabel when you turn it back on)
Indeed, thanks Paul. Also, I'm sure you actually meant "setenforce 0" :)
I cannot use "setenforce 0" because this problem only happens when booting. But I have tried with selinux=0 in grub and doesn't fix the problem. Now I'm thinking it's something related to systemd, because I do "journalctl -f -a -n1000 -b _SYSTEMD_UNIT=tor.service" and don't get any log entry in the current boot. With "systemctl status tor.service" I only see messages of PID 1: tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled) Active: failed (Result: start-limit) since mar 2013-08-27 18:26:00 CEST; 5min ago Process: 1554 ExecStop=/bin/kill -INT ${MAINPID} (code=killed, signal=INT) Process: 1552 ExecStart=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --quiet (code=exited, status=255) ago 27 18:26:00 xenon.miceliux.com systemd[1]: Unit tor.service entered failed state. ago 27 18:26:00 xenon.miceliux.com systemd[1]: tor.service holdoff time over, scheduling restart. ago 27 18:26:00 xenon.miceliux.com systemd[1]: Stopping Anonymizing overlay network for TCP... ago 27 18:26:00 xenon.miceliux.com systemd[1]: Starting Anonymizing overlay network for TCP... ago 27 18:26:00 xenon.miceliux.com systemd[1]: tor.service start request repeated too quickly, refusing to start. ago 27 18:26:00 xenon.miceliux.com systemd[1]: Failed to start Anonymizing overlay network for TCP. ago 27 18:26:00 xenon.miceliux.com systemd[1]: Unit tor.service entered failed state. I have done a clean reinstall of Fedora 19 since last time I reported, and now I have NetworkManager disabled, because I've configured a network bridge and I use the old network scripts.
Can you please try removing the --quiet switch from /usr/lib/systemd/system/tor.service and reboot. Tor should be more verbose about the problem.
(In reply to Christian Stadelmann from comment #6) There is no message from tor itself, only from systemd. The system has been updated to F20, the relevant package versions are: tor-0.2.3.25-1931.fc20.x86_64 systemd-208-9.fc20.x86_64 systemd-libs-208-9.fc20.x86_64 # systemctl status -a -n1000 tor tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled) Active: failed (Result: start-limit) since mar 2013-12-10 08:43:19 CET; 5min ago Process: 1181 ExecStop=/bin/kill -INT ${MAINPID} (code=killed, signal=INT) Process: 1180 ExecStart=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc (code=exited, status=255) Main PID: 1180 (code=exited, status=255) CGroup: /system.slice/tor.service dic 10 08:43:19 lithium.miceliux.com systemd[1]: tor.service: main process exited, code=exited, status=255/n/a dic 10 08:43:19 lithium.miceliux.com systemd[1]: Unit tor.service entered failed state. dic 10 08:43:19 lithium.miceliux.com systemd[1]: tor.service holdoff time over, scheduling restart. dic 10 08:43:19 lithium.miceliux.com systemd[1]: Stopping Anonymizing overlay network for TCP... dic 10 08:43:19 lithium.miceliux.com systemd[1]: Starting Anonymizing overlay network for TCP... dic 10 08:43:19 lithium.miceliux.com systemd[1]: Started Anonymizing overlay network for TCP. dic 10 08:43:19 lithium.miceliux.com systemd[1]: tor.service: main process exited, code=exited, status=255/n/a dic 10 08:43:19 lithium.miceliux.com systemd[1]: Unit tor.service entered failed state. dic 10 08:43:19 lithium.miceliux.com systemd[1]: tor.service holdoff time over, scheduling restart. dic 10 08:43:19 lithium.miceliux.com systemd[1]: Stopping Anonymizing overlay network for TCP... dic 10 08:43:19 lithium.miceliux.com systemd[1]: Starting Anonymizing overlay network for TCP... dic 10 08:43:19 lithium.miceliux.com systemd[1]: tor.service start request repeated too quickly, refusing to start. dic 10 08:43:19 lithium.miceliux.com systemd[1]: Failed to start Anonymizing overlay network for TCP. dic 10 08:43:19 lithium.miceliux.com systemd[1]: Unit tor.service entered failed state.
Usually tor writes the additional data to some log file. try journalctl or any log file in /var/log/tor. btw: You might check your tor configuration with $ tor --check-config or try running tor yourself with the given parameters systemd uses. I had the same problem, in my case there was just some config gone wrong.
Tor is now at version 0.2.4.22 on all branches. The --quiet option has also been removed by default. Is your problem still reproducible?
Created attachment 918206 [details] tor.service log This is tor-0.2.4.22-2.fc20.x86_64 with two ORPorts (IPv4 and IPv6). If I start it manually, it works.
Got a solution. I'm on Fedora 20, using tor-0.2.4.22-2.fc20.x86_64 and I have the same problem. My output is the same as Juan's. My syslog says: Jul 28 09:26:25 localhost Tor[789]: Couldn't open "/var/lib/tor/lock" for locking: Permission denied Jul 28 09:26:25 localhost Tor[789]: set_options(): Bug: Acting on config options left us in a broken state. Dying. The perms on this folder are: drwx------. 2 toranon toranon 4096 11.06.2014 19:46 tor/ Which according to: $ sudo grep toranon /usr/share/tor/defaults-torrc User toranon ... are correct. The files inside the directory however are not owned by that user: $ sudo ls /var/lib/tor/ -l -rw-------. 1 _tor _tor 19391 Jun 9 18:21 cached-certs -rw-------. 1 _tor _tor 1221344 Jul 7 20:32 cached-microdesc-consensus -rw-------. 1 _tor _tor 3036871 Jul 3 19:11 cached-microdescs -rw-------. 1 _tor _tor 799490 Jul 4 19:24 cached-microdescs.new -rw-------. 1 _tor _tor 0 Jul 5 02:47 lock -rw-------. 1 _tor _tor 5705 Jul 7 20:41 state So a quick sudo chown -R toranon:toranon /var/lib/tor/ fixed the problem, now my tor is working again. Looks like maybe the package maintainer changed the user, but didn't take into account pre existing installs?
The upstream torproject.org repository contains a tor package that uses "_tor" user, whereas we use "toranon" user. Solution would be a "chown" during a post installation/upgrade scriptlet. Juan, can you confirm if your problem is identical to Casey's?
All the files in my /var/lib/tor are owned by toranon:toranon I have dealt with bug #1119818 recently and I suspect that is the problem. Do you know if tor uses IP_FREEBIND sockopt when binding to IPv6 addresses? My network interface is a bridge with STP enabled, so it's slow to bring up the port in forwarding state, and I see this warning in the log related to the IPv6 address: [warn] Could not bind to 2001:db8::1:9001: Cannot assign requested address I'll do more test today adding network-online.target as a dependency.
Created attachment 952017 [details] Tor fails to start at boot up I've upgraded to F21, with tor version: tor-0.2.4.25-1.fc21.x86_64 I've created the file /etc/systemd/system/tor.service with: .include /usr/lib/systemd/system/tor.service [Unit] After=network-online.target Requires=network-online.target In my torrc I have ORPort 9001 ORPort [2001:db8::1]:9001 See the attached log of tor failing to start at boot up. If I do systemctl start tor, it starts fine.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Same thing happened to me on F22 with Tor v0.2.6.10 (git-58c51dc6087b0936) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1k-fips and Zlib 1.2.8 systemctl status tor ● tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled) Active: failed (Result: start-limit) since sre 2015-07-22 19:14:04 CEST; 1s ago Process: 13300 ExecStart=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc (code=exited, status=1/FAILURE) Process: 13294 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS) Main PID: 13300 (code=exited, status=1/FAILURE) jul 22 19:14:04 Mk5 systemd[1]: tor.service: main process exited, code=exited, status=1/FAILURE jul 22 19:14:04 Mk5 systemd[1]: Unit tor.service entered failed state. jul 22 19:14:04 Mk5 systemd[1]: tor.service failed. jul 22 19:14:04 Mk5 systemd[1]: tor.service holdoff time over, scheduling restart. jul 22 19:14:04 Mk5 systemd[1]: start request repeated too quickly for tor.service jul 22 19:14:04 Mk5 systemd[1]: Failed to start Anonymizing overlay network for TCP. jul 22 19:14:04 Mk5 systemd[1]: Unit tor.service entered failed state. jul 22 19:14:04 Mk5 systemd[1]: tor.service failed.
Make sure, that the /run/tor directory is existing and writable. InaccessibleDirectories = /home ReadOnlyDirectories = / ReadWriteDirectories = /run/tor ReadWriteDirectories = /var/lib/tor ReadWriteDirectories = /var/log/tor NoNewPrivileges = yes
My /usr/lib/systemd/system/tor.service looks like this: [Unit] Description = Anonymizing overlay network for TCP After = syslog.target network.target nss-lookup.target [Service] Type = simple ExecStartPre = /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config ExecStart = /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc ExecReload = /bin/kill -HUP ${MAINPID} KillSignal = SIGINT TimeoutSec = 30 Restart = on-failure LimitNOFILE = 32768 PrivateTmp = yes DeviceAllow = /dev/null rw DeviceAllow = /dev/urandom r InaccessibleDirectories = /home ReadOnlyDirectories = / ReadWriteDirectories = /var/lib/tor ReadWriteDirectories = /var/log/tor [Install] WantedBy = multi-user.target
I created /run/tor, since it was not existing, but it still refuses to start.
Please, remember to also add ReadWriteDirectories = /run/tor
Changed tor.service to: [Unit] Description = Anonymizing overlay network for TCP After = syslog.target network.target nss-lookup.target [Service] Type = simple ExecStartPre = /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config ExecStart = /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc ExecReload = /bin/kill -HUP ${MAINPID} KillSignal = SIGINT TimeoutSec = 30 Restart = on-failure LimitNOFILE = 32768 PrivateTmp = yes DeviceAllow = /dev/null rw DeviceAllow = /dev/urandom r InaccessibleDirectories = /home ReadOnlyDirectories = / ReadWriteDirectories = /run/tor ReadWriteDirectories = /var/lib/tor ReadWriteDirectories = /var/log/tor NoNewPrivileges = yes [Install] WantedBy = multi-user.target It still fails: ● tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled) Active: failed (Result: start-limit) since sre 2015-07-29 10:59:33 CEST; 2s ago Process: 22762 ExecStart=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc (code=exited, status=1/FAILURE) Process: 22758 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS) Main PID: 22762 (code=exited, status=1/FAILURE) jul 29 10:59:33 Mk5 systemd[1]: tor.service: main process exited, code=exited, status=1/FAILURE jul 29 10:59:33 Mk5 systemd[1]: Unit tor.service entered failed state. jul 29 10:59:33 Mk5 systemd[1]: tor.service failed. jul 29 10:59:33 Mk5 systemd[1]: tor.service holdoff time over, scheduling restart. jul 29 10:59:33 Mk5 systemd[1]: start request repeated too quickly for tor.service jul 29 10:59:33 Mk5 systemd[1]: Failed to start Anonymizing overlay network for TCP. jul 29 10:59:33 Mk5 systemd[1]: Unit tor.service entered failed state. jul 29 10:59:33 Mk5 systemd[1]: tor.service failed.
Just as a note, tor does run if initiated directly from the terminal. Jul 29 11:04:18.515 [notice] Tor v0.2.6.10 (git-58c51dc6087b0936) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1k-fips and Zlib 1.2.8. Jul 29 11:04:18.515 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jul 29 11:04:18.515 [notice] Read configuration file "/etc/tor/torrc". Jul 29 11:04:18.521 [notice] Opening Socks listener on 127.0.0.1:9050 Jul 29 11:04:18.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jul 29 11:04:18.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jul 29 11:04:18.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Jul 29 11:04:18.000 [notice] Bootstrapped 0%: Starting Jul 29 11:04:20.000 [notice] Bootstrapped 5%: Connecting to directory server Jul 29 11:04:20.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Jul 29 11:04:20.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection Jul 29 11:04:20.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus Jul 29 11:04:20.000 [notice] Bootstrapped 25%: Loading networkstatus consensus Jul 29 11:04:21.000 [notice] Bootstrapped 45%: Asking for relay descriptors Jul 29 11:04:21.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2067/6378, and can only build 3% of likely paths. (We have 30% of guards bw, 31% of midpoint bw, and 30% of exit bw = 3% of path bw.) Jul 29 11:04:21.000 [notice] Bootstrapped 51%: Loading relay descriptors Jul 29 11:04:23.000 [notice] Bootstrapped 57%: Loading relay descriptors Jul 29 11:04:23.000 [notice] Bootstrapped 67%: Loading relay descriptors Jul 29 11:04:24.000 [notice] Bootstrapped 77%: Loading relay descriptors Jul 29 11:04:25.000 [notice] Bootstrapped 80%: Connecting to the Tor network Jul 29 11:04:25.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jul 29 11:04:25.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jul 29 11:04:25.000 [notice] Bootstrapped 100%: Done
InaccessibleDirectories = /home ReadOnlyDirectories = / will prevent (write) access to everything. Please, check that all directories and files mentioned in tor.service and /etc/tor/torrc are writable by the tor user and allowed by the ReadWriteDirectories parameter in tor.service
Heh, it was some weird user ownage. /var/lib/tor was is owned by toranon [root@Mk5 ~]# cd /var/lib [root@Mk5 lib]# ls -l .... drwx------. 2 toranon toranon 4096 jul 13 16:31 tor but the files in it were owned by _tor [root@Mk5 tor]# ls -l total 7628 -rw-------. 1 _tor _tor 20092 jul 15 18:44 cached-certs -rw-------. 1 _tor _tor 1281268 jul 22 17:49 cached-microdesc-consensus -rw-------. 1 _tor _tor 5469480 jul 19 23:29 cached-microdescs -rw-------. 1 _tor _tor 1025677 jul 21 20:39 cached-microdescs.new -rw-------. 1 _tor _tor 0 jul 19 22:59 lock -rw-------. 1 _tor _tor 2075 jul 22 16:43 state Once I cleaned out this dir and restarted the service via systemctl everything worked as expected. The files are now owned by the proper user. [root@Mk5 ~]# ls -l /var/lib/tor total 4364 -rw-------. 1 toranon toranon 20092 jul 29 18:19 cached-certs -rw-------. 1 toranon toranon 1260390 jul 29 18:19 cached-microdesc-consensus -rw-------. 1 toranon toranon 3176677 jul 29 18:21 cached-microdescs -rw-------. 1 toranon toranon 854 jul 29 18:21 cached-microdescs.new -rw-------. 1 toranon toranon 0 jul 29 18:21 lock -rw-------. 1 toranon toranon 974 jul 29 18:23 state
Hello, I am experiencing the same kind of troubles, I have tried all the possible solutions suggested in this thread, but none help. I also updated systemd, but still no success. ● tor.service - Anonymizing overlay network for TCP Loaded: loaded (/usr/lib/systemd/system/tor.service; disabled; vendor preset: disabled) Active: failed (Result: start-limit) since Mon 2015-11-02 21:28:37 CET; 10s ago Process: 2809 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config (code=exited, status=255) Nov 02 21:28:37 localhorst systemd[1]: tor.service: control process exited, code=exited status=255 Nov 02 21:28:37 localhorst systemd[1]: Failed to start Anonymizing overlay network for TCP. Nov 02 21:28:37 localhorst systemd[1]: Unit tor.service entered failed state. Nov 02 21:28:37 localhorst systemd[1]: tor.service failed. Nov 02 21:28:37 localhorst systemd[1]: tor.service holdoff time over, scheduling restart. Nov 02 21:28:37 localhorst systemd[1]: start request repeated too quickly for tor.service Nov 02 21:28:37 localhorst systemd[1]: Failed to start Anonymizing overlay network for TCP. Nov 02 21:28:37 localhorst systemd[1]: Unit tor.service entered failed state. Nov 02 21:28:37 localhorst systemd[1]: tor.service failed. I would really appreciate the help.
Please, also see https://bugzilla.redhat.com/show_bug.cgi?id=1247216