Bug 77086 - Unable to sync system time
Summary: Unable to sync system time
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ntp
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-31 22:43 UTC by Milan Kerslager
Modified: 2007-04-18 16:48 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-02-14 21:02:09 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2002:230 0 normal SHIPPED_LIVE New ntp package fixes a bug in parsing command line options 2002-10-10 04:00:00 UTC

Description Milan Kerslager 2002-10-31 22:43:10 UTC
I'm unable to use ntpdate to sync time&date because too big offset:

# ntpdate tak.cesnet.cz
 2 Nov 01:36:50 ntpdate[1581]: Can't adjust the time of day: Invalid argument
# ntptrace tak.cesnet.cz
tak.cesnet.cz: stratum 1, offset -93634.278879, synch distance 0.00157, refid 'GPS'
# date 10312339
# ntpdate tak.cesnet.cz
31 Oct 23:39:11 ntpdate[1588]: step time server 195.113.144.238 offset 6.853757 sec

Seems odd error message or stupid bug... I don not remember same problem with
old version of ntpdate (without libcap) but I could be wrong (I did not tested it).

Comment 1 John I Wang 2002-11-08 16:13:49 UTC
I've noticed this problem with the RedHat 8.0 distribution.   It's not a problem
with ntp but a problem with dhcpcd.   Apparently, it fails to make the entry:
   restrict NTP-SERVER
in the /etc/ntp.conf file (where NTP-SERVER is the ip-address or name provided
via DHCP).   Since it does make the entry:
   restrict default ignore
the end result is that ntp is effectively blocked from syncing with anyone.

I was about to submit it as a dhcpc bug but decided to check the ntp bugs to see
if someone else had encountered the issue.

Comment 2 Milan Kerslager 2002-11-11 13:59:44 UTC
Seems to be two different bugs. I had no ntp daemon running and I did not used
dhcpd to obtain IP address. I'm only using ntpdate to sync time every hour
(because ntp daemon was not so fail-proof).

What I did is try to use with ntpdate to change local time and it refused to do
because "bad argument". This is odd. The second problem is that script for ntpd
daemon is using ntpdate to sync time like I did, but this simply not work when
time offset is too big as I reported.

I'm reopening to point that there is an inconsistency.

Comment 3 Harald Hoyer 2002-11-11 15:58:10 UTC
ok, found the bug in the source.. .thx for reporting...

Comment 4 Tim Coote 2002-12-13 09:31:47 UTC
I had problems with ntp that relate to the default ignore entry in the 
ntp.conf. they didn't come from dhcp, I think it's just the defaul entry in 
the config file.

Also: 
- ntp doesn't log that it's not synching. in fact there's no indication that 
anything's wrong unless you happen to do a manual clock check
- there's no warning from ntp that it's got a stupid configuration. in fact 
it's not trivial to find that it's getting the returned signals correctly and 
then throwing them away. (I faffed for ages checking firewall settings, and 
ethereal to be sure that something was going on at all.


Comment 5 Harald Hoyer 2003-01-09 15:25:51 UTC
should be fixed with ntp-4.1.1b-1

Comment 6 John Flanagan 2003-02-14 21:02:09 UTC
An errata 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 the 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-2002-230.html



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