Description of problem: My tor server starts fine after boot. (Once I realized that systemd expects it NOT to daemonize: i.e. runasdaemon=no .) But, it tries and fails to start automatically on boot. It looks like the network interface isn't fully configured when tor.service is started and, even though it waits and retries a few times, it gives up before the interface is ready. Version-Release number of selected component (if applicable): tor-0.2.1.30-1501.fc15.x86_64 How reproducible: So far, always. Steps to Reproduce: 1. systemctl enable tor.service 2. systemctl start tor.service 3. If tor started fine, reboot Actual results: Tor will try but fail to start on boot. Requires manual start via systemctl Expected results: Tor should start on boot. Additional info:
I don't know if this is helpful, but here's what I'm seeing in syslog: (hostname changed) ... Jul 18 16:00:54 hostname kernel: [ 18.885242] systemd[1]: systemd 26 running in system mode. (+PAM +LIBWRAP +AU DIT +SELINUX +SYSVINIT +LIBCRYPTSETUP; fedora) Jul 18 16:00:54 hostname kernel: [ 19.102432] NET: Registered protocol family 10 Jul 18 16:00:54 hostname kernel: [ 19.129754] systemd[1]: Set hostname to <hostname>. Jul 18 16:00:54 hostname kernel: [ 19.686492] systemd[1]: [/lib/systemd/system/tor.service:14] Failed to parse time value, ignoring: ${TOR_SHUTDOWN_WAIT} Jul 18 16:00:54 hostname kernel: [ 19.686503] systemd[1]: [/lib/systemd/system/tor.service:16] Failed to parse resource value, ignoring: ${TOR_NOFILE} Jul 18 16:00:54 hostname kernel: [ 20.996167] EXT4-fs (dm-2): re-mounted. Opts: (null) ... Jul 18 16:00:54 hostname kernel: [ 22.699926] 3c59x 0000:05:07.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 ... Jul 18 16:00:54 hostname kernel: [ 31.616893] systemd[1]: tor.service: main process exited, code=exited, status=255 Jul 18 16:00:54 hostname kernel: [ 31.717744] dbus[1189]: avc: netlink poll: error 4 Jul 18 16:00:54 hostname systemd[1]: tor.service: main process exited, code=exited, status=255 Jul 18 16:00:54 hostname systemd[1]: tor.service holdoff time over, scheduling restart. Jul 18 16:00:54 hostname systemd[1]: Unit tor.service entered failed state. Jul 18 16:00:54 hostname systemd[1]: tor.service: main process exited, code=exited, status=255 Jul 18 16:00:54 hostname systemd[1]: tor.service holdoff time over, scheduling restart. Jul 18 16:00:54 hostname kernel: [ 32.175244] eth1: setting full-duplex. Jul 18 16:00:54 hostname systemd[1]: Unit tor.service entered failed state. Jul 18 16:00:54 hostname systemd[1]: tor.service: main process exited, code=exited, status=255 Jul 18 16:00:54 hostname systemd[1]: tor.service holdoff time over, scheduling restart. Jul 18 16:00:54 hostname systemd[1]: Unit tor.service entered failed state. Jul 18 16:00:54 hostname systemd[1]: tor.service: main process exited, code=exited, status=255 Jul 18 16:00:54 hostname systemd[1]: tor.service holdoff time over, scheduling restart. Jul 18 16:00:54 hostname systemd[1]: Unit tor.service entered failed state. Jul 18 16:00:54 hostname systemd[1]: tor.service: main process exited, code=exited, status=255 Jul 18 16:00:54 hostname systemd[1]: tor.service holdoff time over, scheduling restart. Jul 18 16:00:54 hostname systemd[1]: Unit tor.service entered failed state. Jul 18 16:00:54 hostname systemd[1]: tor.service start request repeated too quickly, refusing to start. ...
(on i386) adding nss-lookup.target dependence - delays tor startup (named runs on the box) file /lib/systemd/system/tor.service: [Unit] Description = Anonymizing overlay network for TCP After = syslog.target network.target nss-lookup.target ......
Interesting. syslog.target appears to be almost nearly the last target reached on my system, assuming I'm reading the output of list-units correctly. The only target after systlog is "time-sync.target". I'll try adding that, but it's still not clear why the the included dependency on syslog.target is insufficient.
I've added nss-lookup.target dependence to all services which require name resolution (tor,ntpd,ntpdate...) and now "startup" log is clean - all services starts correctly no boot. I`m not systemd expert and maybe it`s not right workaround but it works for me ;)
Nope. No joy. Let us know if we can do anything to help, Enrico.
Rebooted. This time, it doesn't appear systemd even tried to start tor.service. I don't see any failure messages in syslog, yet tor.service did not start. As usual, manually calling on systemctl to start tor.service was successful. tor.service is still enabled, according to systemctl is-enabled. There doesn't seem to be anyway to find out what systemd was thinking during boot. Baffling.
tor-0.2.2.33-1600.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/tor-0.2.2.33-1600.fc16
tor-0.2.1.30-1502.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/tor-0.2.1.30-1502.fc15
Package tor-0.2.1.30-1502.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing tor-0.2.1.30-1502.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/tor-0.2.1.30-1502.fc15 then log in and leave karma (feedback).
Excellent. I will test within the next few weeks.
tor-0.2.1.30-1502.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
tor-0.2.2.33-1600.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.