Bug 1476999
| Summary: | ddclient doesn't wait until network is online | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christopher Tubbs <ctubbsii> |
| Component: | ddclient | Assignee: | Scott Talbert <swt> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 26 | CC: | i, jrowens.fedora, swt, thomas |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ddclient-3.8.3-5.fc26 ddclient-3.8.3-5.fc27 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-09-19 03:24:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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`