Martin,
Thank you for you bug report. Not that I necessarily have a specific openrdate
bugtracking service ('cause this whole project was really just for my own
benefit), but it's still interesting to see what others have been up to with
it. That said, I take your point about the use (or non-use, in this case) of
the adjtime(x) function. However, there's a couple of points:
1) You will note in the rdate (8) manpage that there is the option:
-a Use the adjtime(2) call to gradually skew the local time to the
remote time rather than just hopping.
I don't see that being used for in your tests (not that that makes them
invalid, but I think you're comparing apples to oranges without it). I would
speculate (but I haven't cracked open the ntpdate code to find out) that
ntpdate "automatically" employs adjtime(x) whereas rdate requires an explicit
call for it to be used. It would be interesting to see whether the use of the
'-a' option would still cause rdate to malfunction.
2) As I said earlier, this was basically for my own use and is just a
(hopefully) platform-neutral means of having rdate (since I don't like netdate
and having to load all of ntp is a waste of space). Having a (hopefully)
platform-neutral stance and wanting to stick as closely to possible to the
original OpenBSD code (since they know a h**l of a lot more than I do about C
coding), I won't (and wouldn't) move the rdate adjustment call to adjtimex as
netdate has done. As you will note in the CONFORMING TO section of the
adjtimex(2) manpage:
adjtimex() is Linux-specific and should not be used in programs
intended to be portable. See adjtime(3) for a more portable, but less
flexible, method of adjusting the system clock.
As such, I am unwilling to implement this function in the current rdate code.
While I have introduced compile-time opt-outs for Linux, this was based on the
announced retirement of the 'sysctl' function [1] (as alerted to me by another
Debian user). The current rdate code does reference the adjtime(3) function
[2], and I think I'll stick with it because, as I said, the OpenBSD coders know
a h**l of a lot more than me about C coding.
Once again, thank you for your report. If you should happen to run the below
tests again, employing the '-a' option with rdate, and rdate _still_ breaks,
I'd be glad to know what the results are.
Sincerely,
David Snyder
[1] http://lwn.net/Articles/247243/
[2] rdate.c, line 159
----- Original Message ----
From: Martin Michlmayr <[email protected]>
To: David Snyder <[email protected]>
Cc: [email protected]; Bill Gatliff <[email protected]>
Sent: Thu, October 29, 2009 2:59:54 PM
Subject: Re: Bug#502336: fails to date date when computer has very old time
Hi David,
Here is a bug report for rdate that I believe was never forwarded to
you. We run rdate in the Debian installer to set the time. We
support some devices on which the time (for various reasons) is really
broken, like 1902 or 2039. In those cases, rdate fails to set the
time correctly. However, ntpdate works just fine.
Here's an example:
> debian:~# date
> Tue Sep 9 20:18:34 CET 1902
> debian:~# rdate -o 123 -nvv -p 0.debian.pool.ntp.org
> .
> Sun Sep 27 23:32:42 CET 1970
> rdate: adjust local clock by 2147481499.516352 seconds
> debian:~# rdate -o 123 -nvv 0.debian.pool.ntp.org
> .
> rdate: Could not set time of day: Invalid argument
> debian:~# ntpdate 0.debian.pool.ntp.org
> 15 Oct 19:47:01 ntpdate[2094]: step time server 81.223.14.147 offset
> -946713599.360574 sec
> debian:~# date
> Wed Oct 15 19:47:03 CEST 2008
> debian:~#
> debian:~# rdate -o 123 -nvv 0.debian.pool.ntp.org
> .
> Wed Oct 15 19:48:52 CEST 2008
> rdate: adjust local clock by -0.003934 seconds
I ran strace on rdate and ntpdate to see why one works whereas the
other doesn't:
rdate does:
> gettimeofday({2203525639, 202585}, NULL) = 0
> gettimeofday({2203525639, 203778}, NULL) = 0
> settimeofday({56041989, 2148687426}, NULL) = -1 EINVAL (Invalid argument)
whereas ntpdate does this:
> gettimeofday({2203525668, 219220}, NULL) = 0
> adjtimex({modes=ADJ_OFFSET|0x8000, offset=0, freq=0, maxerror=16000000,
> esterror=16000000, status=STA_UNSYNC, constant=2, precision=1,
> tolerance=32768000, time={2203525668, 220471}, tick=10000, ppsfreq=0,
> jitter=0, shift=0, stabil=0, jitcnt=0, calcnt=0,errcnt=0, stbcnt=0}) = 5
> (TIME_ERROR)
> settimeofday({1256840868, 673856}, NULL) = 0
> gettimeofday({1256840868, 675101}, NULL) = 0
I don't know anything about adjtimex but do you think it would be
possible for rdate to support this too?
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
