The ddclient bug exhibits itself with two errors I would see in the system log and also kindly emailed to me by the ddclient daemon itself:
WARNING: cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.org'or the more generic error:
WARNING: cannot connect to 192.168.0.1:80 socket: IO::Socket::INET: connect: Network is unreachableThe issue seems to be that ddclient, a Perl client that talks to dynamic DNS services like dyndns.org, has problems either making network connections or perhaps caches a bad address at system start when networking services might not yet be up. This problem with ddclient seems longstanding, with a bug filed in 2003 on the Debian list and a bug filed in 2009 on the Red Hat list.
The Red Hat bug was closed May 29 with a fix (ddclient-184.108.40.206) posted to update sites for Fedora 11 and later. But if you have not or cannot update, or still see the bug, here's my workaround: Instead of using ddclient's built-in web client to connect to your dynamic-DNS service, call a shell script that uses curl to make the network call. Specifically, I replaced this line in my /etc/ddclient.conf configuration file:
use=web, web=checkip.dyndns.org/, web-skip='IP Address' # found after IP Addresswith this line:
use=cmd, cmd=/home/tom/bin/checkip.sh, cmd-skip='IP Address' # found after IP AddressHere is my checkip.sh shell script, stored in my home "bin" directory:
#!/bin/sh # # A script to fill in for what ddclient # can't seem to do: reliably connect to checkip.dyndns.org. curl http://checkip.dyndns.org/That's it. The only extra steps you need to take are to ensure the user that runs your ddclient daemon (typically user "ddclient") has access to the script. That means in my case making sure the script itself is executable, e.g. chmod 755 ~/bin/checkip.sh, and that my home directory and bin directory are world executable, e.g. chmod --recursive o+x ~/bin/checkip.sh
When I eventually upgrade my system and use version 220.127.116.11 of ddclient, I look forward to seeing if this longstanding networking bug really got fixed.