Bug 719476
| Summary: | tor.service fails to start at/on/during boot, but works fine after. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul DeStefano <prd-fedora> |
| Component: | tor | Assignee: | Enrico Scholz <rh-bugzilla> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | cassmodiah, lmacken, mszafranski, rh-bugzilla, vezza |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | tor-0.2.1.30-1502.fc15 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-09-20 23:54:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Paul DeStefano
2011-07-07 00:47:41 UTC
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. |