Description of problem: A correctly-configured nut-server can fail to start first time on boot. Version-Release number of selected component (if applicable): nut-2.7.4-26.el8.x86_64 How reproducible: Always (on my system, but may be timing-dependent) Steps to Reproduce: 1. Configure nut-server, and enable it to start on boot 2. Reboot system and connect via terminal/SSH 3. Check if nut-server is running. Observe that it is not. 4. systemctl restart nut-server 5. Observe that nut-server is now running Actual results: nut-server is not running. System log shows something like this: 08:46:10 HOSTNAME systemd[1]: Started Network UPS Tools - power devices information server. 08:46:11 HOSTNAME upsd[1534]: fopen /var/run/nut/upsd.pid: No such file or directory 08:46:11 HOSTNAME upsd[1534]: not listening on [REDACTED_LAN_IP] port 3493 08:46:11 HOSTNAME upsd[1534]: not listening on [REDACTED_LAN_IP] port 3493 08:46:11 HOSTNAME upsd[1534]: listening on 127.0.0.1 port 3493 08:46:11 HOSTNAME upsd[1534]: listening on 127.0.0.1 port 3493 08:46:11 HOSTNAME upsd[1534]: no listening interface available 08:46:11 HOSTNAME upsd[1534]: no listening interface available 08:46:11 HOSTNAME upsd[1534]: Network UPS Tools upsd 2.7.4 08:46:11 HOSTNAME systemd[1]: nut-server.service: Main process exited, code=exited, status=1/FAILURE 08:46:11 HOSTNAME systemd[1]: nut-server.service: Failed with result 'exit-code'. After "systemctl restart nut-server", the service starts correctly. Expected results: nut-server runs on start Additional info: It looks like nut-server is starting before the network is ready. The systemd unit file probably needs to include "After=network.target"
I realised that the unit file already has "After=network.target", so that alone doesn't solve the problem. However, I have more information about this: - It's apparently triggered by the configuration of an IP address other than 127.0.0.1 ("LISTEN x.y.z.a" configuration option in upsd.conf) and occurs when the x.y.z.a interface is not ready at the time upsd starts up - The solution is to change "After=network.target" to "After=network-online.target" in nut-server.service => According to https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ , this is less desirable than "After=network.target", but as I understand it from that article, the primary solution to avoid it for a server that can be configured to listen on an arbitrary address seems to be for the server to use the IP_FREEBIND socket option (which upsd apparently does not, at least by grepping the code). So, unless and until upsd upstream changes this, waiting for "network-online.target" seems to be the best option. - Along the way I found that, *if* listening on all interfaces is an acceptable solution, "LISTEN 0.0.0.0" works, and does not suffer from this issue. => Workaround for some use cases
I ran into exactly the same issue today and was about to file a bug report when I found this one. Thanks to OP for saving me some time writing it up, I hope this will be fixed soon.
Same here - same problem, and came to the same conclusion of changing the After to "network-online.target" as the least offending solution.