Description of problem: When the Prosody service is set to autostart, the service starts before the network interfaces are up/ready. This results in outgoing Prosody network connections to fail. Version-Release number of selected component (if applicable): Arch : x86_64 Epoch : 0 Version : 0.9.8 Release : 4.fc22 How reproducible: Often or always. (Always in my case, tested on different servers and setups) Steps to Reproduce: - Install prosody (dnf install prosody) - Add a virtual host in /etc/prosody/conf.d - Set prosody to autostart: systemctl enable prosody - reboot the system: shutdown -r now Actual results: Warning appearing in /var/log/prosody/prosody.log: >> Aug 23 16:40:13 mod_s2s warn No local IPv4 or IPv6 addresses detected, outgoing connections may fail Indeed, outgoing s2s connections are not working. Expected results: Outgoing s2s connections should work as expected and the warning should not appear in the /var/log/prosody/prosody.log file. Additional info: The problem does not occur when starting prosody manually via "systemctl start prosody.service" when the network interfaces are up. One possible way to fix this problem is to change "After=network.target" to "After=network-online.target" in the the file /usr/lib/systemd/system/prosody.service. With this change, Prosody starts up fine (without the warning) and s2s connections work as expected.
Created attachment 1066066 [details] prosody.service Changed After=network.target to After=network-online.target
Thank you for your report and the analysis. I contacted upstream for an opinion regarding this while I consider your suggestion as the way to go.
Upstream here. Haven't seen this before, though it makes sense that it would happen if Prosody is started before networking is up. Based on this, there are a couple of changes we are considering: - Delaying this check until the first outgoing s2s connection is attempted - Re-scanning local interfaces on SIGHUP However regardless of these potential changes, I don't think it makes any sense to start a network service daemon when there is no network available. As systemd supports this, I think it's entirely sensible to make the proposed change to prosody.service.
prosody-0.9.8-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14492
prosody-0.9.8-5.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14493
prosody-0.9.8-5.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14494
prosody-0.9.8-5.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7835
prosody-0.9.8-5.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update prosody'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14494
prosody-0.9.8-5.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update prosody'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14493
prosody-0.9.8-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.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update prosody'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7835
prosody-0.9.8-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update prosody'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14492
prosody-0.9.8-5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
prosody-0.9.8-5.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
prosody-0.9.8-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
prosody-0.9.8-5.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
I have the same problem. With After=network-online.target in usr/lib/systemd/system/prosody.service.
Sébastien, which version of Prosody do you use exactly? And what does "rpm -q prosody" say?
$ rpm -q prosody prosody-0.9.12-1.fc25.x86_64
"systemctl cat prosody.service" should contain "After=network-online.target", which was the scope of this bug report.
$ systemctl cat prosody.service # /usr/lib/systemd/system/prosody.service [Unit] Description=Prosody XMPP (Jabber) server After=network-online.target [Service] Type=forking PIDFile=/run/prosody/prosody.pid ExecStart=/usr/bin/prosodyctl start ExecReload=/usr/bin/prosodyctl reload ExecStop=/usr/bin/prosodyctl stop [Install] WantedBy=multi-user.target
So "After=network-online.target" exists, which is a point where the network should be working. Can you describe your network setup? Currently, I am more tempted to say that this is likely to be a network misconfiguration.
# cat /etc/sysconfig/network-scripts/ifcfg-enp2s0 HWADDR= TYPE=Ethernet BOOTPROTO=none DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=enp2s0 UUID= ONBOOT=yes IPADDR=192.168.1. PREFIX=24 GATEWAY=192.168.1.1 DNS1=192.168.1.1 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_PRIVACY=no
(In reply to Robert Scheck from comment #21) Any idea?