Description of problem: While the system bootes ddclient starts and prints the following message to /var/log/messages: ddclient[#]: WARNING: cannot connect to checkip.x31.eu:80 socket: IO::Socket::INET: Bad hostname 'checkip.x31.eu' which I think indicates that it cant resolve the IP-address of (my) site which returns your current public IP-address. This is valid at this time, as the network connection is not fully established. After the system is booted the network connection is established (via Networkmanager) and usable. When ddclient retries it still fails and prints the same message. It retries every 5 Minutes and always fails until system is shutdown. "nslookup checkip.x31.eu" works without any problem. When I use /etc/hosts to "fix" the IP from checkip.x31.eu the hostname from the site where my dyndns has to be registered fails: ddclient[#]: WARNING: cannot connect to dyndns.strato.com:443 socket: IO::Socket::SSL: Bad hostname 'dyndns.strato.com' IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0) which confirms to me that its a problem with ddclient resolving the address. "nslookup dyndns.strato.com" also works without any problem. If you see ddclient spamming the logs with its messages and you restart it using /etc/init.d/ddclient restart it magically fixes all problems and the registration works without any change to the internet connection at all. If the system somehow looses its internet connection (its a Notebook) and reconnects after ddclient had a scheduled IP-check it fails all over again and restarting fixes it again. Version-Release number of selected component (if applicable): Name : ddclient Arch : noarch Version : 3.7.3 Release : 2.fc11 How reproducible: every time Steps to Reproduce: 0. Notebook running Fedora 11, mostly on hardwired internet connection (using DHCP), default Network connection setup by Fedora installer (using Networkmanager) 1. install ddclient 2. configure ddclient (/etc/ddclient.conf) 3. enable ddclient at boot time using "chkconfig ddclient on" 4. reboot system 5. view logfile (/var/log/messages), notice ddcient fails to update 6. try nslookup on failing hostname to make sure internet connection is working 7. restart ddclient (/etc/init.d/ddclient restart) 8. view logfile (/var/log/messages), notice ddcient updates fine Actual results: - logfile states ddclient failed to resolve hostname - dyndns account doesn't get updated Expected results: - logfile states ddclient updated dyndns account OR no messages form ddclient when no update necessary - dyndns account is up-to-date Additional info: none
I have the same problem here. I tried moving it to a later place by shifting startup numbers to S96ddclient, but that didn't help. Two solutions to the problem: 1. Make the startup somehow dependent on the network connection, so that ddclient starts when the machine is online or 2. Fix ddclient so it can resolve hostnames after network status has changed. This would be the best way, I think. Imagine a scenario where you have a laptop and the internet connection becomes available after you plug in the cable... If there is anything I can help testing, let me know. Thanks! Tobias
Same problem here, only using another dynamic DNS service. The inadyn dynamic DNS client (1.96.2-4) shows the same behavior, even if it by default uses other start and stop priority levels. This is apparently an old problem; the discussion at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201295 contains a suggestion that the error may be caused by the fact that resolv.conf isn't populated when ddclient starts and it is never re-read by libc.
Well. This is strange. Even when I'm starting it up as a new one from the command line with a valid server in my resolv.conf, I'm still getting "WARNING: cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.org'". And that's only after I comment out the "Multihomed => 1" line in the IO::Socket::INET->new; with that line in there, it just quietly dies. ...Oh, crud. I think I've just determined that perl and IO::Socket::INET is quite incompatible with "options inet6" in one's resolv.conf. Removing that got me an update. I doubt that that's a problem for most users, though. Now that I've figured that out, back to work on how to solve the initial startup problem, and perhaps off to file a bug on perl....
yeah i see this one too
Two things: 1. It happens in F12. (as it has gone gold since last week when rawhide pushed the F12 repo files, and I am receiving new packages from the F12 Updates repo, I'm pretty sure I am already running it :-)). 2. jrowens, could you set this bug as confirmed and add it to the F12 pool?
This is happening to me in F12 exactly as described in the initial report.
Folks, the problem here seems to be that NetworkManager is started after the ddclient, that means after X logon. Or do you use the classical things?
I used/use NetworkManager (see 0 in "Steps to Reproduce:"), but I don't see any way of fixing it robustly by starting ddclient after NM, because it will then still fail if you somehow loose your connection. And this happens more often than not.
Sorry, I overlooked this. Try the following script. If it works, I'll include it into the next update of ddclient. Note that it is completely untested, but should not eat your baby, maybe simply not work in the worse case... ;-) Create "/etc/NetworkManager/dispatcher.d/50-ddclient" file, "chmod 755" to it and use the following content: --- snipp --- #!/bin/sh export LC_ALL=C if [ "$2" = "down" ]; then /sbin/ip route ls | grep -q '^default' || { [ -f /var/lock/subsys/ddclient ] && /sbin/service ddclient stop || : } && { :; } fi if [ "$2" = "up" ]; then /sbin/ip -o route show dev "$1" | grep -q '^default' && { /sbin/chkconfig ddclient && /sbin/service ddclient start || : } || { :; } fi --- snapp --- May I get feedback for this, whether it works for you? It of course does not disable the error at booting time, that's the next thing. The initscript from bug #551906 also needs to be adapted for this, once this dispatcher works.
Sorry, can't help because I use "the classical things" ;) Anybody else please step forward. Thanks.
On F11 I had the same iussue wrote by linux. Additional I've tried to set to off NetworkManager and set to on network: the problem was solved. Then I've tried the original configuration (NetworkManager on) with your script /etc/NetworkManager/dispatcher.d/50-ddclient. After a reboot the problem was present, in my /var/log/messages there was the warning again: ddclient[1715]: WARNING: cannot connect to checkip.dyndns.com:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.com' I hope it can help you.
Silvio, can you try to apply my additional fix for the initscript itself? https://bugzilla.redhat.com/show_bug.cgi?id=246903#c8 - both together (my patch and the script from above) should make the issue going away. Please let me know, if you need help or so.
Right! I've tried the init script you've posted in the Bug 246903, and added the line '[ ! -f /var/lock/subsys/network -a ! -f /var/lock/subsys/NetworkManager ] && exit 0' The result: # /etc/init.d/ddclient start /etc/init.d/ddclient: line 29: /etc/sysconfig/ddclient: No such file or directory I've got not ddclient file in my /etc/sysconfig! Maybe there's something obvious that I don't know?
Bah, that's another bug. Comment out the ". /etc/sysconfig/ddclient" line or create the /etc/sysconfig/ddclient file. I'll investigate into this as well.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Already working on that as the package owner seems to be AWOL.
ddclient-3.8.0-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.fc13
ddclient-3.8.0-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.fc12
ddclient-3.8.0-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.fc11
ddclient-3.8.0-1.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.el5
ddclient-3.8.0-1.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.el4
Removing wrong "Security" keyword (this is not security-related).
ddclient-3.8.0-1.el4 has been pushed to the Fedora EPEL 4 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ddclient'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.el4
ddclient-3.8.0-1.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ddclient'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.el5
ddclient-3.8.0-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ddclient'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.fc12
ddclient-3.8.0-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ddclient'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.fc11
ddclient-3.8.0-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ddclient'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.fc13
I'm not sure if it's some odd problem with my setup, but the dispatcher doesn't seem to be working with ddclient-3.8.0-1.fc12 - I see log messages like: nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/50-ddclient' could not be executed: not executable by owner. /etc/NetworkManager/dispatcher.d/50-ddclient seems to have its permissions set to 0644, unlike the other dispatcher scripts which are 0755.
Theodore, try "chmod 755 /etc/NetworkManager/dispatcher.d/50-ddclient" and let me please know whether it solves the issue.
Adding execute permissions to the script stops the log messages popping up, so I guess that means it's running successfully. I haven't seen ddclient throw any bad hostname warnings yet either, although it hasn't been running for too long. I'll keep an eye on it and let you know.
I haven't seen ddclient exhibit any problems after running for about a day. It still throws hostname warnings occasionally, but those only seem to occur when my network connection is on the blink for whatever reason (they're mixed in with connection timeouts). Mostly it just performs successful updates.
Still working for you since the permissions have been fixed?
The permissions fix seems to have resolved the problem - everything's working fine. =)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
ddclient-3.8.0-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/ddclient-3.8.0-2.fc13
ddclient-3.8.0-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/ddclient-3.8.0-2.fc12
ddclient-3.8.0-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/ddclient-3.8.0-2.fc11
ddclient-3.8.0-2.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/ddclient-3.8.0-2.el5
ddclient-3.8.0-2.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/ddclient-3.8.0-2.el4
Last outstanding issue has been fixed with ddclient-3.8.0-2
ddclient-3.8.0-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
ddclient-3.8.0-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
ddclient-3.8.0-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
ddclient-3.8.0-2.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.
ddclient-3.8.0-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
I'm experiencing this error with Fedora 16 x86_64 and ddclient-3.8.0-4.fc15.noarch I see this error periodically: ddclient[1214]: WARNING: cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: Bad hostname 'checkip.dyndns.org' After restarting the service manually it works.
CentOS 6.x still has an old buggy version (3.7.3). FWIW, I experience this error only when calling ddclient like so: ddclient -daemon=0 There seems to be no error with: ddclient -daemon=0 -verbose However, the first variant is preferred, as it doesn't blow up the log files when executed regularly.
the bug is back again in ddclient-3.8.3.