Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1476999

Summary: ddclient doesn't wait until network is online
Product: [Fedora] Fedora Reporter: Christopher Tubbs <ctubbsii>
Component: ddclientAssignee: Scott Talbert <swt>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: 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:

Description Christopher Tubbs 2017-08-01 03:59:49 UTC
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`

Comment 1 Scott Talbert 2017-08-10 02:55:53 UTC
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.

Comment 2 Christopher Tubbs 2017-08-10 04:58:41 UTC
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

Comment 3 Scott Talbert 2017-09-03 03:49:16 UTC
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.

Comment 4 Christopher Tubbs 2017-09-08 22:43:53 UTC
'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

Comment 5 Scott Talbert 2017-09-09 01:44:03 UTC
Do you mind trying this scratch build to make sure it resolves the problem for you?
https://koji.fedoraproject.org/koji/taskinfo?taskID=21738247

Comment 6 Christopher Tubbs 2017-09-09 02:35:14 UTC
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.

Comment 7 Fedora Update System 2017-09-09 02:57:28 UTC
ddclient-3.8.3-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-71c6eb075b

Comment 8 Fedora Update System 2017-09-09 02:57:56 UTC
ddclient-3.8.3-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c04308b471

Comment 9 Fedora Update System 2017-09-09 19:57:43 UTC
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

Comment 10 Fedora Update System 2017-09-10 05:54:21 UTC
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

Comment 11 Fedora Update System 2017-09-19 03:24:48 UTC
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.

Comment 12 Christopher Tubbs 2017-09-19 21:27:54 UTC
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

Comment 13 Scott Talbert 2017-09-20 14:56:53 UTC
(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?

Comment 14 Christopher Tubbs 2017-09-20 16:31:31 UTC
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.

Comment 15 Fedora Update System 2017-09-30 06:21:41 UTC
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.