Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 8237

Summary: timedc clockdiff <host> doesn't work
Product: [Retired] Red Hat Linux Reporter: Andreas J. Bathe <ajb>
Component: timedAssignee: Preston Brown <pbrown>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-09-25 18:27:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andreas J. Bathe 2000-01-06 18:33:22 UTC
When fiddling with xntp and checking that hosts have the same time
I discovered that there is a bug in the timedc program. You can't
get a reasonable value when executing "timedc clockdiff <host>".
This was checked with version 5.2 till 6.1 where the bug exists.

I compiled the FreeBSD counterpart on RH 6.1 and this check runs as
expected (clockdiff functions).

Comment 1 Derek Tattersall 2000-08-13 19:47:14 UTC
Using timed-0.17-1.1 from RC1 clockdiff <host> with a two station network, one
being the master and one the slave only replies with <host> is down.  However
turning trace on shows that the time demon is running on both machines and the
log shows that the master and the slave recognize each other.

Comment 2 William Greathouse 2000-09-25 18:27:01 UTC
The following patch will correct the problem.  The corrected bug could also
cause a race condition when a Linux server was elected master server.  This race
condition could have catastophic effects on system operation as the systems
continually adjust their time.  I have had the system time advance by 5 years
within a ten minute interval.  The actual time is being extracted from the wrong
point in the message by the measure() function in timed/lib/measure.c.


-------- cut-here: netkit-timed-0.16.patch ----------------
diff -rc netkit-timed-0.16-orig/timed/lib/measure.c
netkit-timed-0.16/timed/lib/measure.c
*** netkit-timed-0.16-orig/timed/lib/measure.c  Mon May 19 05:41:37 1997
--- netkit-timed-0.16/timed/lib/measure.c   Sun Sep 24 13:50:41 2000
***************
*** 234,240 ****
--- 234,244 ----
                continue;

            /* Reset this because icp just changed... */
+ #ifndef icmp_data
            icp_time = (time_t *)(icp + 1);
+ #else
+           icp_time = (time_t *)icp->icmp_data;
+ #endif

            sendtime = ntohl(icp_time[0]);
            recvtime = ((tcur.tv_sec % SECDAY) * 1000 +
-------- end cut -----------------

Apply from within netkit-timed-0.16 directory using 
"patch -p1 < netkit-timed-0.16-patch"



Comment 3 Preston Brown 2001-02-01 18:11:08 UTC
we are obsoleting timed in our next release; many aspects of the protocol are
broken compared to ntp, and we are advocating users to use that solution
instead.