Bug 506286
Summary: | ddclient fails to resolve host names | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | linux |
Component: | ddclient | Assignee: | Robert Scheck <redhat-bugzilla> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | brian, bugs, chricki, enpontus, jorti, jrowens.fedora, palopezv, redhat-bugzilla, red, renard, theo148, tottmar |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | ddclient-3.8.0-2.el5 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-05-29 11:08:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
linux
2009-06-16 15:07:19 UTC
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.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.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.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.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/ddclient-3.8.0-1.el4 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. |