Bug 532136

+++ This bug was initially created as a clone of Bug #450301 +++

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;

--- Additional comment from reloftin.com on 2008-07-17 08:43:48 EDT ---

This issue unchanged in version 5.2

--- Additional comment from dcantrell on 2008-09-26 00:01:15 EDT ---

This should be easy enough to fix.  Thanks for the report and sorry it didn't get picked up sooner for a RHEL update.

--- Additional comment from dcantrell on 2009-02-20 21:31:51 EDT ---

Fixed in dhcp-3.0.5-19.el5 and later releases.

--- Additional comment from atodorov on 2009-05-08 05:06:28 EDT ---

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.

--- Additional comment from rssjames on 2009-07-17 12:38:53 EDT ---

Looks like the fix for this is in RHEL 5.4 beta (currently at dhclient-3.0.5-21).

--- Additional comment from errata-xmlrpc on 2009-09-02 06:13:09 EDT ---

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

--- Additional comment from reloftin.com on 2009-10-30 09:32:22 EDT ---

(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.

--- Additional comment from dcantrell on 2009-10-30 15:24:14 EDT ---

(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.

--- Additional comment from reloftin.com on 2009-10-30 16:02:10 EDT ---

(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.