Description of problem: ddclient does not wait until the network is online before starting and retrieving the public IP address. The systemd unit is configured to start after 'network.target' (/usr/lib/systemd/system/ddclient.service): After=syslog.target network.target nss-lookup.target However, after booting, often, the service cannot get online to determine its public IP address. Typing `sudo systemctl status ddclient.service` shows DNS errors looking up the hostname for the public IP service. I believe this is caused by the service starting up too quickly, and not waiting for the network to come online ('network.target' comes up immediately after 'network-pre.target'). It may be better for it to specify 'Wants=network-online.target'. At the very least, 'After=network-online.target' would be better. Version-Release number of selected component (if applicable): ddclient-3.8.3-3.fc26.noarch How reproducible: (system-dependent) Steps to Reproduce: 1. Configure ddclient with lookup service for public IP (for example: `use=web, web=dynamicdns.park-your-domain.com/getip`) 2. Reboot 3. sudo systemctl status ddclient.service Actual results: Sometimes see errors resolving hostname, because ddclient started before the network was fully available. Expected results: ddclient should wait until the network is online. There should be no issues resolving the DNS name because the host should be online. Additional info: I started seeing this problem in F24, but in F26, it's worse, perhaps because F26 seems to boot faster (for me). In F25, the problem would occur after boot about 30% of the time. In F26, it's closer to 100% of the time. I have an SSD, so my boot times are very fast. The workaround is to restart the service: `sudo systemctl restart ddclient.service`
I presume you don't use NetworkManager? There's supposed to be a hook that starts ddclient when NetworkManager connects to a network, but that wouldn't help if you don't use it.
No, I definitely am using NetworkManager. I don't know about the hook you speak of. I'm using the systemd unit which comes with the ddclient package in Fedora. The only "hook" I know of is the network-online.target which is set by NetworkManager when the network connects. ddclient isn't waiting for this, though... it's waiting for just network.target
OK, it sounds like network-online.target is the way to go. What's the difference between 'Wants' and 'After'? I did a little reading on that, but I'm still not sure I understand.
'Wants', like 'Requires' triggers the other service to start. Don't use that. 'After' is simple ordering. That's what it should use. https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BUnit%5D%20Section%20Options
Do you mind trying this scratch build to make sure it resolves the problem for you? https://koji.fedoraproject.org/koji/taskinfo?taskID=21738247
Just checked. I cannot reproduce the problem after installing the updated RPM. So, it looks like it's working great! If you tag the update, I'll give karma in Bodhi.
ddclient-3.8.3-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-71c6eb075b
ddclient-3.8.3-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c04308b471
ddclient-3.8.3-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-71c6eb075b
ddclient-3.8.3-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c04308b471
ddclient-3.8.3-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Unfortunately, the fix didn't work. It's still a good improvement, but apparently, what I'm seeing is an old bug which came back in version 3.8.3, according to the last comment on bz#506286
(In reply to Christopher Tubbs from comment #12) > Unfortunately, the fix didn't work. It's still a good improvement, but > apparently, what I'm seeing is an old bug which came back in version 3.8.3, > according to the last comment on bz#506286 Hmmm, so I thought you said that the network-online.target change fixed the problem for you? So, does it work for you some percentage of the time?
Yeah, I thought it had, because it stopped happening when I tried. I was wrong. It still happens often, but not always. I still think network-online is a better target (because there's no possibility of DNS working before that), but it wasn't a complete fix. Upon further investigation, it seems this is a regression of a old problem that may have been fixed previously. Something to do with the way NetworkManager rewrites resolv.conf but glibc doesn't re-read it after the ddclient daemon process started. Probably need to file an upstream bug to change the way DNS is handled. A workaround might be too change how ddclient.service works, and not run it as a daemon. Probably worth a separate bug since this one is closed and addressed a different issue.
ddclient-3.8.3-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.