Description of problem: tor fails to start at boot-time if ORPort/DirPort is used with <IP>:port. manually starting the service after the system booted with systemctl start tor.3.4_443 works fine. Version-Release number of selected component (if applicable): tor-0.2.6.10-4.fc23.x86_64 How reproducible: always Steps to Reproduce: If you want to reproduce this you can checkout this ansible role (commit acbc71fe22175d5bd4e6b60d59e204e57fec8cb3): https://github.com/nusenu/ansible-relayor run it against a fresh Fedora 23 installation and reboot. NOT working config: -------------- RunAsDaemon 1 User toranon PidFile /var/run/tor/1.2.3.4_443.pid Log notice file /var/log/tor/1.2.3.4_443.log DataDirectory /var/lib/tor/1.2.3.4_443 ORPort 1.2.3.4:443 DirPort 1.2.3.4:9001 Address 1.2.3.4 OutboundBindAddress 192.168.0.31 SocksPort 0 --------------- diff to get it to work (but not a real solution for the problem): < ORPort 1.2.3.4:443 < DirPort 1.2.3.4:9001 --- > ORPort 443 > DirPort 9001 Actual results: tor log: [notice] Opening OR listener on 1.2.3.4:443 [warn] Could not bind to 1.2.3.4:443: Cannot assign requested address the host is configured to use this IP address statically so it should be available right from the start Expected results: tor should start up normally Additional info: I'm using the multi-instance service file shipped with the package, but the problem is also reproducible with the default systemd service file getsebool -a|grep tor tor_bind_all_unreserved_ports --> off tor_can_network_relay --> on (but I can exclude SELinux as the root cause since I disabled it to make sure it isn't the problem)
Unfortunately, I cannot reproduce this issue on a fresh F23 virtual machine. Perhaps the network interface is slow to initialize. Tor should restart on failure, so perhaps set RestartSec=5 (which tells systemd to wait 5 seconds after a service fails before restarting it) and see if that fixes the issue after a reboot. Also, as an aside: 1. RunAsDaemon is ignored because tor.service runs tor with `--runasdaemon 0` on the command-line (which overrides any torrc option). 2. Unless you use the PidFile in any scripts, it isn't needed by systemd or anything else, so there's no need to create one. 3. I didn't run your ansible thing, but I just had a look at your centos_tor@.service and Type=simple should be Type=notify, and you're missing `--runasdaemon 0` in ExecStartPre. Also, systemd hardening works fine with SELinux (except for CapabilityBoundingSet, but I'm working on that with upstream).
(In reply to Jamie Nguyen from comment #1) > Unfortunately, I cannot reproduce this issue on a fresh F23 virtual machine. > Perhaps the network interface is slow to initialize. Tor should restart on > failure, so perhaps set RestartSec=5 (which tells systemd to wait 5 seconds > after a service fails before restarting it) and see if that fixes the issue > after a reboot. RestartSec=1 does the trick, thank you! (Wouldn't the proper solution be to start network services once interfaces are ready in the first place?) > Also, as an aside: > 1. RunAsDaemon is ignored because tor.service runs tor with `--runasdaemon > 0` on the command-line (which overrides any torrc option). Yes I'm aware of it (but I didn't bother to remove that line on Linux systems, since it does no harm). > 3. I just had a look at your > centos_tor@.service thanks for reviewing it, I'll reconsider retesting the hardening features on centos, for fedora I'm using your service file with a few modifications https://github.com/nusenu/ansible-relayor/commit/2149edf99fe1c251d0eaad5c78536c9b1d54dde3 > Type=simple should be Type=notify, and If I set it to notify tor constantly dies and starts again, with simple I don't have that problem (maybe the torproject's build do not work with notify?) > you're > missing `--runasdaemon 0` in ExecStartPre. Does that matter with --verify-config (it doesn't start a daemon and exits after verifying)? (I added it anyway) > Also, systemd hardening works > fine with SELinux (except for CapabilityBoundingSet, but I'm working on that > with upstream). see also: https://lists.fedoraproject.org/pipermail/selinux/2015-April/016634.html thanks!
(In reply to nusenu from comment #2) > RestartSec=1 > does the trick, thank you! > (Wouldn't the proper solution be to start network services once interfaces > are ready in the first place?) This is what After=network.target is meant to do. I'm not sure why in your case it isn't working. I haven't experienced the same issue you're having. > > 1. RunAsDaemon is ignored because tor.service runs tor with `--runasdaemon > > 0` on the command-line (which overrides any torrc option). > > Yes I'm aware of it (but I didn't bother to remove that line on Linux > systems, since it does no harm). It's confusing for whoever is using your ansible role. > > 3. I just had a look at your > > centos_tor@.service > > thanks for reviewing it, I'll reconsider retesting the hardening features on > centos, for fedora I'm using your service file with a few modifications > https://github.com/nusenu/ansible-relayor/commit/ > 2149edf99fe1c251d0eaad5c78536c9b1d54dde3 > > > Type=simple should be Type=notify, and > > If I set it to notify tor constantly dies and starts again, with simple I > don't have that problem (maybe the torproject's build do not work with > notify?) If systemd development headers (eg, systemd-devel package on Fedora/CentOS) are available at build time, then Tor builds with sd_notify support. > > you're > > missing `--runasdaemon 0` in ExecStartPre. > > Does that matter with --verify-config (it doesn't start a daemon and exits > after verifying)? > (I added it anyway) It likely doesn't make a difference, but (in an abundance of caution) better to make ExecStartPre exactly the same as ExecStart (except for --verify-config).
Since I'm transitioning to your packages (and your service file), would you mind including: RestartSec=1 in your service file? (it doesn't any bad to others I guess).
For services that attach to network interfaces (which can sometimes be slow to initialize), I do think that the default RestartSec of 100ms is too short. I've added RestartSec=1 and I don't think this will have an adverse effect. Updates to follow.
tor-0.2.7.5-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-0cddd695da
tor-0.2.7.5-5.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-a57c00bb26
tor-0.2.7.5-5.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-cf74a6540d
tor-0.2.7.5-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-0cddd695da
tor-0.2.7.5-5.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-a57c00bb26
tor-0.2.7.5-5.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'yum --enablerepo=epel-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-cf74a6540d
tor-0.2.7.6-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c13ba0f430
tor-0.2.7.6-3.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9c43216367
tor-0.2.7.6-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4b8fcfd778
tor-0.2.7.6-3.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9c43216367
tor-0.2.7.6-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c13ba0f430
tor-0.2.7.6-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'yum --enablerepo=epel-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4b8fcfd778
tor-0.2.7.6-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-bfda6099e2
tor-0.2.7.6-4.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-8185ed15cf
tor-0.2.7.6-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-b870fb3c4e
tor-0.2.7.6-4.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8185ed15cf
tor-0.2.7.6-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-bfda6099e2
tor-0.2.7.6-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'yum --enablerepo=epel-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-b870fb3c4e
tor-0.2.7.6-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
tor-0.2.7.6-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
tor-0.2.7.6-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.