Bug 974477 - tor.service start request repeated too quickly. Tor fails to start at boot
tor.service start request repeated too quickly. Tor fails to start at boot
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: tor (Show other bugs)
20
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jamie Nguyen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-14 05:02 EDT by Juan Orti
Modified: 2015-11-02 18:14 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 20:39:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tor.service log (11.68 KB, text/plain)
2014-07-15 13:26 EDT, Juan Orti
no flags Details
Tor fails to start at boot up (12.78 KB, text/plain)
2014-10-30 05:15 EDT, Juan Orti
no flags Details

  None (edit)
Description Juan Orti 2013-06-14 05:02:50 EDT
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
Comment 1 Juan Orti 2013-06-19 05:10:40 EDT
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.
Comment 2 Jamie Nguyen 2013-06-20 01:44:56 EDT
Thanks for reporting. Could you try disabling SELinux with selinux=0 in GRUB kernel config and then try again?
Comment 3 Paul Wouters 2013-06-20 12:43:06 EDT
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)
Comment 4 Jamie Nguyen 2013-06-20 12:46:44 EDT
Indeed, thanks Paul. Also, I'm sure you actually meant "setenforce 0" :)
Comment 5 Juan Orti 2013-08-27 12:53:58 EDT
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.
Comment 6 Christian Stadelmann 2013-12-07 21:47:45 EST
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.
Comment 7 Juan Orti 2013-12-10 02:56:54 EST
(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.
Comment 8 Christian Stadelmann 2013-12-10 05:00:14 EST
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.
Comment 9 Jamie Nguyen 2014-06-29 13:29:35 EDT
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?
Comment 10 Juan Orti 2014-07-15 13:26:46 EDT
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.
Comment 11 Casey Link 2014-07-28 03:30:49 EDT
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?
Comment 12 Jamie Nguyen 2014-07-31 12:43:58 EDT
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?
Comment 13 Juan Orti 2014-08-04 04:01:55 EDT
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.
Comment 14 Juan Orti 2014-10-30 05:15:55 EDT
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.
Comment 15 Fedora End Of Life 2015-05-29 05:07:21 EDT
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.
Comment 16 Fedora End Of Life 2015-06-29 20:39:15 EDT
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.
Comment 17 techouse 2015-07-22 13:17:56 EDT
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.
Comment 18 Joergen Thomsen 2015-07-28 07:37:35 EDT
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
Comment 19 techouse 2015-07-28 08:09:12 EDT
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
Comment 20 techouse 2015-07-28 08:10:15 EDT
I created /run/tor, since it was not existing, but it still refuses to start.
Comment 21 Joergen Thomsen 2015-07-28 20:12:48 EDT
Please, remember to also add

ReadWriteDirectories = /run/tor
Comment 22 techouse 2015-07-29 05:00:33 EDT
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.
Comment 23 techouse 2015-07-29 05:10:09 EDT
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
Comment 24 Joergen Thomsen 2015-07-29 11:57:38 EDT
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
Comment 25 techouse 2015-07-29 12:26:06 EDT
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
Comment 26 steiner.sebastian 2015-11-02 15:29:18 EST
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.
Comment 27 Joergen Thomsen 2015-11-02 18:14:37 EST
Please, also see https://bugzilla.redhat.com/show_bug.cgi?id=1247216

Note You need to log in before you can comment on or make changes to this bug.