Bug 450301 - dhclient restarts ntpd when not necessary
dhclient restarts ntpd when not necessary
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcp (Show other bugs)
5.1
All Linux
low Severity low
: rc
: ---
Assigned To: David Cantrell
Alexander Todorov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-06 11:13 EDT by Ron Loftin
Modified: 2009-10-30 16:02 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 532136 (view as bug list)
Environment:
Last Closed: 2009-09-02 06:13:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ron Loftin 2008-06-06 11:13:49 EDT
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;
Comment 1 Ron Loftin 2008-07-17 08:43:48 EDT
This issue unchanged in version 5.2
Comment 2 David Cantrell 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.
Comment 4 David Cantrell 2009-02-20 21:31:51 EST
Fixed in dhcp-3.0.5-19.el5 and later releases.
Comment 6 Alexander Todorov 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@1.1570-o 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.
Comment 8 Rob James 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).
Comment 9 errata-xmlrpc 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
Comment 10 Ron Loftin 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.
Comment 11 David Cantrell 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.
Comment 12 Ron Loftin 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.  

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.

Note You need to log in before you can comment on or make changes to this bug.