Description of problem: The /sbin/dhclient-script assumes that there is a useful value in the $localClockFudge variable, but this is not always the case. When $localClockFudge is empty, the dhclient-script adds an empty line to /etc/ntp.conf when renewing the DHCP lease. This causes the "diff" command to fail when there is no meaningful difference between the old and new files, thus restarting the NTP daemon unnecessarily. This puts useless noise in the log files that gets picked up by logwatch, and should be done away with. Version-Release number of selected component (if applicable): dhclient-3.0.5-7.el5 How reproducible: always Steps to Reproduce: 1. Remove fudge options from /etc/ntp.conf ( use external server only ) 2. Configure client for DHCP IP address 3. Observe actions at DHCP lease renewal Actual results: See Description of problem Expected results: See Description of problem Additional info: Reported as CentOS bug #0002799 A possible fix is to modify /sbin/dhclient-script by modifying line 421: Old: echo "$localClockFudge" >> /etc/ntp.conf; New: [ -n "$localClockFudge" ] && echo "$localClockFudge" >> /etc/ntp.conf;
This issue unchanged in version 5.2
This should be easy enough to fix. Thanks for the report and sorry it didn't get picked up sooner for a RHEL update.
Fixed in dhcp-3.0.5-19.el5 and later releases.
with dhclient-3.0.5-18.el5 - NOT fixed: May 8 05:02:55 gs-bl460cg1-01 NET[6850]: /sbin/dhclient-script : updated /etc/resolv.conf May 8 05:02:55 gs-bl460cg1-01 ntpd[6108]: ntpd exiting on signal 15 May 8 05:03:03 gs-bl460cg1-01 ntpdate[6871]: no server suitable for synchronization found May 8 05:03:03 gs-bl460cg1-01 ntpd[6873]: ntpd 4.2.2p1 Wed Sep 3 14:28:15 UTC 2008 (1) May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: precision = 1.000 usec May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: Listening on interface wildcard, 0.0.0.0#123 Disabled May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: Listening on interface wildcard, ::#123 Disabled May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: Listening on interface lo, ::1#123 Enabled May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: Listening on interface eth0, fe80::21f:29ff:feeb:5266#123 Enabled May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: Listening on interface lo, 127.0.0.1#123 Enabled May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: Listening on interface eth0, 10.16.65.170#123 Enabled May 8 05:03:03 gs-bl460cg1-01 ntpd[6874]: kernel time sync status 0040 May 8 05:03:04 gs-bl460cg1-01 kernel: bnx2: eth0: using MSI May 8 05:03:04 gs-bl460cg1-01 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready May 8 05:03:04 gs-bl460cg1-01 kernel: bnx2: eth0 NIC SerDes Link is Up, 1000 Mbps full duplex May 8 05:03:04 gs-bl460cg1-01 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready May 8 05:03:04 gs-bl460cg1-01 dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 May 8 05:03:04 gs-bl460cg1-01 dhclient: DHCPACK from 10.16.64.14 May 8 05:03:05 gs-bl460cg1-01 NET[7258]: /sbin/dhclient-script : updated /etc/resolv.conf May 8 05:03:05 gs-bl460cg1-01 dhclient: bound to 10.16.65.170 -- renewal in 34786 seconds. May 8 05:03:09 gs-bl460cg1-01 ntpd[6874]: frequency initialized 81.411 PPM from /var/lib/ntp/drift with dhclient-3.0.5-21.el5 - FIXED May 8 05:04:52 gs-bl460cg1-01 NET[7477]: /sbin/dhclient-script : updated /etc/resolv.conf May 8 05:04:53 gs-bl460cg1-01 kernel: bnx2: eth0: using MSI May 8 05:04:53 gs-bl460cg1-01 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready May 8 05:04:53 gs-bl460cg1-01 kernel: bnx2: eth0 NIC SerDes Link is Up, 1000 Mbps full duplex May 8 05:04:53 gs-bl460cg1-01 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready May 8 05:04:53 gs-bl460cg1-01 dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 May 8 05:04:53 gs-bl460cg1-01 dhclient: DHCPACK from 10.16.64.14 May 8 05:04:53 gs-bl460cg1-01 NET[7861]: /sbin/dhclient-script : updated /etc/resolv.conf May 8 05:04:53 gs-bl460cg1-01 dhclient: bound to 10.16.65.170 -- renewal in 38885 seconds.
Looks like the fix for this is in RHEL 5.4 beta (currently at dhclient-3.0.5-21).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1331.html
(In reply to comment #8) > Looks like the fix for this is in RHEL 5.4 beta (currently at > dhclient-3.0.5-21). I'm afraid not. By the time this version of dhclient got to me as dhclient-3.0.5-21, the fix proposed above lost one of the '&' characters, which makes it revert to the old behavior. I just found this as I only upgraded to 5.4 this week.
(In reply to comment #10) > (In reply to comment #8) > > Looks like the fix for this is in RHEL 5.4 beta (currently at > > dhclient-3.0.5-21). > > I'm afraid not. By the time this version of dhclient got to me as > dhclient-3.0.5-21, the fix proposed above lost one of the '&' characters, which > makes it revert to the old behavior. > > I just found this as I only upgraded to 5.4 this week. Yeah, I'm seeing that. Odd. Oh well, only thing to do now is file a bug for RHEL 5.4 and ask for the fix in 5.5. Not sure how this passed QA at the end.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #8) > > > Looks like the fix for this is in RHEL 5.4 beta (currently at > > > dhclient-3.0.5-21). > > > > I'm afraid not. By the time this version of dhclient got to me as > > dhclient-3.0.5-21, the fix proposed above lost one of the '&' characters, which > > makes it revert to the old behavior. > > > > I just found this as I only upgraded to 5.4 this week. > > Yeah, I'm seeing that. Odd. Oh well, only thing to do now is file a bug for > RHEL 5.4 and ask for the fix in 5.5. Not sure how this passed QA at the end. Is it really necessary to go through the whole bug process all over again, or is there a shorter process to deal with a QA failure? It seems kind of silly to wait for the next point release for something this trivial, especially since this issue has been pushed to the back burner ever since 5.1.