ntpd sets clock to the year 1939
Robert Dodier
I am working with embedded Linux systems (Gumstix) which appear to
lack
a persistent clock so whenever they are rebooted, their system clocks
go
back to January 1, 1970. I am hoping to use ntpd to set the clock on
these
systems but I am getting an unexpected result.
When I run ntpd on the Gumstix, without the -g option it complains
that the
time difference between the local clock and the server is too great.
OK, I expected that. However, when I run it again with -g, ntpd
happily
makes a big adjustment in the local time ... changing it from 1970 to
1939 for some reason. I tried a couple of different servers but got
the same
result.
Here's the content of /etc/ntp.conf (sans most of the comments):
restrict default nomodify notrap noquery
restrict 127.0.0.1
# server 0.pool.ntp.org
# server 1.pool.ntp.org
# server 2.pool.ntp.org
server time.cachenetworks.com
driftfile /var/lib/ntp/drift
Here's the output from /var/log/messages.
The first output is without -g option and second one is with -g.
...
Dec 31 16:04:34 gumstix daemon.err ntpd[447]: time correction of
-972551638 seconds exceeds sanity limit (1000); set clock manually to
the correct UTC time.
...
Mar 8 06:51:15 gumstix daemon.notice ntpd[467]: time reset
-972551637.925997 s
Now -972551637 = -31 years, approximately, so that's how the date is
set to 1939
from 1970. However, it is not a simple sign inversion: the correct
time adjustment
should be more like +37 years.
I'm really stumped. Any light you can shed on this problem is much
appreciated.
Robert Dodier
Robert Dodier
Richard B. gilbert
I believe that there is a limit to the date/time range that ntpd can
handle and that it's something like 36 years. Try setting the date
manually to something a little closer to being current. If it's off by
less than 36 years, I think ntpd will handle it correctly. A startup
script that set the date to a reasonable approximation; e.g. 2007 would
probably solve your problem and work for the next 36 years or so.
Robert Dodier
wrote:
> I believe that there is a limit to the date/time range that ntpd can
> handle and that it's something like 36 years. Try setting the date
> manually to something a little closer to being current. If it's off by
> less than 36 years, I think ntpd will handle it correctly. A startup
> script that set the date to a reasonable approximation; e.g. 2007 would
> probably solve your problem and work for the next 36 years or so.
Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
was
able to handle the rest. It seems odd to me that ntpd gets confused by
too large a time difference, but oh well, it's OK the way it is.
Thanks for your help,
Robert Dodier
Richard B. gilbert
It's hardly ever a problem since most systems have a hardware clock of
some sort that can supply a reasonable starting point. In 2007, I don't
think that 1970-is a reasonable starting point.
Harlan Stenn
60-odd years of the correct date, and this was after he did some work to
expand this from the previous limit of 30-odd years.
I forget the exact number offhand.
It is possible there is an arithmetic overflow or signed/unsigned problem
somewhere.
I'd love to see this documented somewhere easy to find and also get a test
case going.
H
David J Taylor
[]
> It's hardly ever a problem since most systems have a hardware clock of
> some sort that can supply a reasonable starting point. In 2007, I
> don't think that 1970-is a reasonable starting point.
Whilst I have some sympathy for that viewpoint, NTP should not today have
that 30-year limitation (delighted to hear it is being extended).
It is not a defect of the OS that it allows its real-time clock to be set
/before/ the base time - 1970?
David
Richard B. gilbert
The "30-year" limitation is really, I believe, 36 years. It's a
artifact of the data structures used by the current implementation; a
sixty-four bit word with the binary point in the middle is used to
represent the seconds and fractional seconds since 1-JAN-1970. This has
served us well for the last 20 years or so. I believe that the new
standard is going to call for a 128 bit word which should last a few
years longer. :-)
The fault, if any, is the way Unix keeps time. I believe it's a signed
32 bit integer keeping seconds since 1-JAN-1970. Digital's VMS used a
scheme that could represent any time from a base time in November 1857
through the next 30,000 years or so. Unix time, at least until
recently, would overflow in 2036.
Marc Brett
"Be liberal in what you accept, conservative in what you send."
We may not think that 1970 is a reasonable starting point, but these systems
exist today and ntpd should deal gracefully with them. In fact, a POSIX time of
0 is not exactly an unreasonable starting date for a system with no hardware
clock and no DHCP-specified NTP server.
It's unfortunate that applications (especially an application dedicated to
keeping the correct time, fer cryin out loud) fall over when faced with such a
time value, but whose fault is that?
Richard B. gilbert
The opposite argument would be that it's not reasonable for ntpd to make
a "leap of faith" and jump the time by 36 years! Ntpd is designed to
consider a clock that's off by 1024 seconds or more as a situation it is
not equipped to handle. Ntpd is behaving as it's designed and
documented to behave.
The source is available and anyone with the necessary skills can modify
it to handle special cases like this. Anyone lacking the necessary
skills can pay someone with the skills to do the work.
Marc Brett
<rgilb...@comcast.net> wrote:
>Marc Brett wrote:
>> On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert"
>> <rgilb...@comcast.net> wrote:
>>>Robert Dodier wrote:
>>>>On Mar 26, 12:50 pm, "Richard B. gilbert" <rgilber...@comcast.net>
>>>>wrote:
>>>>>I believe that there is a limit to the date/time range that ntpd can
>>>>>handle and that it's something like 36 years. Try setting the date
>>>>>manually to something a little closer to being current. If it's off by
>>>>>less than 36 years, I think ntpd will handle it correctly. A startup
>>>>>script that set the date to a reasonable approximation; e.g. 2007 would
>>>>>probably solve your problem and work for the next 36 years or so.
>>>>
>>>>Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
>>>>was
>>>>able to handle the rest. It seems odd to me that ntpd gets confused by
>>>>too large a time difference, but oh well, it's OK the way it is.
>>>
>>>It's hardly ever a problem since most systems have a hardware clock of
>>>some sort that can supply a reasonable starting point. In 2007, I don't
>>>think that 1970-is a reasonable starting point.
>>
>> "Be liberal in what you accept, conservative in what you send."
>>
>> We may not think that 1970 is a reasonable starting point, but these systems
>> exist today and ntpd should deal gracefully with them. In fact, a POSIX time of
>> 0 is not exactly an unreasonable starting date for a system with no hardware
>> clock and no DHCP-specified NTP server.
>>
>> It's unfortunate that applications (especially an application dedicated to
>> keeping the correct time, fer cryin out loud) fall over when faced with such a
>> time value, but whose fault is that?
>
>The opposite argument would be that it's not reasonable for ntpd to make
>a "leap of faith" and jump the time by 36 years!
But 26 years, say, is perfectly reasonable?
>Ntpd is designed to
>consider a clock that's off by 1024 seconds or more as a situation it is
>not equipped to handle. Ntpd is behaving as it's designed and
>documented to behave.
But it isn't. The "ntpd -g" documentation says:
-g
Normally, ntpd exits with a message to the system log if the offset exceeds the
panic threshold, which is 1000 s by default. This option allows the time to be
set to any value without restriction; however, this can happen only once.
"Without restriction" means, to me, that time jumps of 26 years, 36 years, or 46
years are all perfectly fine.
>The source is available and anyone with the necessary skills can modify
>it to handle special cases like this. Anyone lacking the necessary
>skills can pay someone with the skills to do the work.
Maybe the gumstix folk can be persuaded...
Greg Dowd
Message: 8
Date: Tue, 27 Mar 2007 07:49:36 GMT
From: "David J Taylor"
<david-...@blueyonder.not-this-bit.nor-this-part.co.uk>
Subject: Re: ntpd sets clock to the year 1939
To: ques...@lists.ntp.isc.org
Message-ID: <k04Oh.499$NK2...@text.news.blueyonder.co.uk>
Richard B. gilbert wrote:
[]
> It's hardly ever a problem since most systems have a hardware clock of
> some sort that can supply a reasonable starting point. In 2007, I
> don't think that 1970-is a reasonable starting point.
Whilst I have some sympathy for that viewpoint, NTP should not today
have that 30-year limitation (delighted to hear it is being extended).
It is not a defect of the OS that it allows its real-time clock to be
set /before/ the base time - 1970?
David
>>>>>>>>>>>>>>>>>>>>
The problem is not so much that NTP has a limitation on bits and an
overflow condition. This is always the case. Dave was able to modify
the code slightly, by switching to a double earlier, and change the
window from 34 years to 68 years. This allowed him to keep that least
significant bit included in the calculation. Never know when those
picoseconds are going to count!
The real problem is, and we've debated this before, that ntp happily
sets the clock to the incorrect time and clears the unsynchronized bits
and reports good health to anyone listening. According to the integer
math, this isn't incorrect time, it simply belongs in another epoch (or
window). If you want to handle this case, it requires additional logic.
The debate then switches to whether it is necessary to force every
implementation to check whether or not the offset is a large negative
value before applying and spit an error if -g isn't set or something
along those lines. Because this is most often an issue for embedded
systems developers, the perception was that these developers should
solve their own problem by initializing the clock to a known value.
We've all pretty much done that but I still debate whether or not this
is the correct approach. The system which are really tripped up by this
are going to be unattended unix or windoze machines initializing to
default clock values. Until a process is in place to correct this, you
would typically expect ntp (the network time protocol) to set the clock
correctly, even if it had to iterate a few times.
Dave had talked about having ntp log an error, and/or die, if it is
invoked on a system where the time difference between the const compile
time and the system time exceeds some window. This doesn't help
embedded systems guys but it might help system operators trying to debug
why ntp can't set time correctly. I don't believe this was ever added
to the codebase.
Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"The current implementation is non-obvious and may need to be improved."
_______________________________________________
questions mailing list
ques...@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions
Robert Dodier
wrote:
> >>It's hardly ever a problem since most systems have a hardware clock of
> >>some sort that can supply a reasonable starting point. In 2007, I don't
> >>think that 1970-is a reasonable starting point.
I dunno. Zero is a pretty common default value.
I'm not surprised the device I'm working with boots up with that date.
> The opposite argument would be that it's not reasonable for ntpd to make
> a "leap of faith" and jump the time by 36 years!
No need for a leap of faith. Jumps larger than the sanity limit
are authorized by the -g option.
> Ntpd is designed to consider a clock that's off by 1024 seconds or
> more as a situation it is not equipped to handle.
Except as modified by the -g option. Let's see what the man page
for ntpd says about that:
-------------- begin quoted text about ntpd -g --------------
Normally, ntpd exits if the offset exceeds the sanity limit, which is
1000 s by default. If the sanity limit is set to zero, no sanity
checking
is performed and any offset is acceptable. This option overrides the
limit and allows the time to be set to any value without restriction;
however, this can happen only once. After that, ntpd will exit if
the
limit is exceeded. This option can be used with the -q option.
--------------- end quoted text about ntpd -g ---------------
It says "any offset", not "any offset less than 30 years".
> Ntpd is behaving as it's designed and documented to behave.
I don't know about the design, but in fact it's documented to behave
otherwise.I searched the ntp documentation and could not find any
mention of the 30-year limitation. It certainly should be in the man
page for ntpd, if it's anywhere.
> The source is available and anyone with the necessary skills can modify
> it to handle special cases like this. Anyone lacking the necessary
> skills can pay someone with the skills to do the work.
Or someone lacking necessary skills can make noise about it
and hope than someone else will get motivated to work on it.
Other people do this to me all the time. I don't see anything
wrong with it. It's often called a request for enhancement.
But maybe it would be enough to just mention the 30 year
limitation in the documentation.
FWIW
Robert Dodier
Richard B. gilbert
> On Mar 27, 9:04 am, "Richard B. gilbert" <rgilber...@comcast.net>
> wrote:
>
>
>>>>It's hardly ever a problem since most systems have a hardware clock of
>>>>some sort that can supply a reasonable starting point. In 2007, I don't
>>>>think that 1970-is a reasonable starting point.
>>>
>
> I dunno. Zero is a pretty common default value.
> I'm not surprised the device I'm working with boots up with that date.
>
>
>>The opposite argument would be that it's not reasonable for ntpd to make
>>a "leap of faith" and jump the time by 36 years!
>
>
> No need for a leap of faith. Jumps larger than the sanity limit
> are authorized by the -g option.
>
Did you start it with the -g option?
>
>>Ntpd is designed to consider a clock that's off by 1024 seconds or
>>more as a situation it is not equipped to handle.
>
>
> Except as modified by the -g option. Let's see what the man page
> for ntpd says about that:
>
> -------------- begin quoted text about ntpd -g --------------
> Normally, ntpd exits if the offset exceeds the sanity limit, which is
> 1000 s by default. If the sanity limit is set to zero, no sanity
> checking
> is performed and any offset is acceptable. This option overrides the
> limit and allows the time to be set to any value without restriction;
> however, this can happen only once. After that, ntpd will exit if
> the
> limit is exceeded. This option can be used with the -q option.
> --------------- end quoted text about ntpd -g ---------------
>
> It says "any offset", not "any offset less than 30 years".
>
>
>>Ntpd is behaving as it's designed and documented to behave.
>
>
> I don't know about the design, but in fact it's documented to behave
> otherwise.I searched the ntp documentation and could not find any
> mention of the 30-year limitation. It certainly should be in the man
> page for ntpd, if it's anywhere.
>
Then perhaps the documentation needs to be updated! The 36 year "epoch"
(if that's the proper term) has been discussed before on this
newsgroup although not recently. Perhaps because it's rare for anyone
to start ntpd with a clock that's off by 37 years! I think you may be
the only person to report such a problem in the four years or so that
I've been reading this newsgroup!
Perhaps a startup script that sets the date to 1-JAN-2007 before
starting ntpd would put a band-aid on the problem.
<snip>
Robert Dodier
> Dave had talked about having ntp log an error, and/or die, if it is
> invoked on a system where the time difference between the const compile
> time and the system time exceeds some window. This doesn't help
> embedded systems guys but it might help system operators trying to debug
> why ntp can't set time correctly. I don't believe this was ever added
> to the codebase.
Well, even if the code is not changed, it would be extremely helpful
to document the actual behavior of ntpd -g.
That way people know that a ballpark date adjustment
is necessary before ntpd can do anything useful.
Even embedded systems guys read man pages ....
FWIW
Robert Dodier
Harlan Stenn
something more to your liking.
I think there are 2 places to lobby:
- Dave
- The IETF NTP WG
I believe Dave's point is that this is trivial to work around - one sets the
initial date to be either somewhere between the time the executable was
compiled and X years *later* - then ntpd starts up and sets the date
correctly. In fact, it will do that for the next X+60ish (unless it's
X+30ish) years.
I would *love* to see the spec include a flag (could be the stratum, could
be something else) that says "The date you are being given is not X.Y
(seconds and fractions of seconds), but is X (all seconds)". This will, I
believe, solve the problem without making the packets bigger.
H
Robert Dodier
> I believe Dave's point is that this is trivial to work around -
It is trivial *once you know it must be done*.
As it stands, ntpd -g happily sets an incorrect date, and there
is no way to know from reading the available documentation or
the program output that there is anything amiss.
At this point all I want is to mention the limitation in the man page.
Robert Dodier
Per Hedeland
<4B73D9EBE2327E40B4D6...@sjmail1.symmetricom.com>
GD...@symmetricom.com (Greg Dowd) writes:
>
>The problem is not so much that NTP has a limitation on bits and an
>overflow condition. This is always the case. Dave was able to modify
>the code slightly, by switching to a double earlier, and change the
>window from 34 years to 68 years. This allowed him to keep that least
>significant bit included in the calculation.
I agree with this basic principle (and the rest of what you wrote), but
I believe that your numbers are off by a factor of two. NTP timestamps
use a 32-bit unsigned quantity for the seconds, with the base year 1900
- this means that the window should be 136 years, and that any point in
time in the range ~ 1900..2036 can be unambiguously represented. I
believe that the fix was to change the effective window from 68 years
(due to what must be considered a bug) to the "proper" 136 years. And I
wonder if this fix is in the version the OP used (not mentioned as far
as I can see).
Assuming a window of 68 years (for whatever reason), timestamps in the
ranges 1900..1968 and 1968..2036 can not be distinguished from each
other, and some assumption has to be made if the current year is 1970
and the time stamp supposedly representing "correct" time can be
interpreted as either 1939 or 2007 - 1939 is definitely closer, and thus
a reasonable choice absent other "additional logic" (such as time of
compilation of the binary that has been mentioned - or in this case even
a hardwired constant in the code). Or put another way, ntpd assumes a
window that is symmetric around the current system time.
OK, I had to test it myself, especially after having been chastised by
Steve in the orphan thread.:-) With ntpd 4.2.0-a (what ships with
FreeBSD 5.4), I saw exactly the same behaviour as the OP - I set the
date to 1970, and ntpd -g hapily set it back to 1939. However ntpd
4.2.4p0 did the right thing:
Jan 1 00:00:26 pelle ntpd[21059]: ntpd 4.2...@1.1472-o Tue Mar 27 22:43:41 UTC
2007 (1)
Mar 28 00:45:25 pelle ntpd[21060]: time reset +1175039090.075990 s
- and in fact it continues to do the right thing if the original date is
as far back as 1940 (too bad my syslogd doesn't show the year:-):
Jan 1 00:00:09 pelle ntpd[21110]: ntpd 4.2...@1.1472-o Tue Mar 27 22:43:41 UTC
2007 (1)
Mar 28 00:54:34 pelle ntpd[21111]: time reset +2121810856.014114 s
- whereas with the original date in 1938, the 136-year window comes into
play, and it decides to interpret the received timestamp as 1871 (67
years off) rather than 2007 (69 years off):
Jan 1 00:00:07 pelle ntpd[21102]: ntpd 4.2...@1.1472-o Tue Mar 27 22:43:41 UTC
2007 (1)
Mar 28 00:52:17 pelle ntpd[21103]: time reset -2110084575.114568 s
- however at this point the Unix internal time representation comes into
play, and we end up at 2007 despite ntpd's efforts to the contrary.:-)
And just to hopefully dispel some myths about *that*, i.e. Unix/POSIX
time representation: First of all it really has nothing to do with NTP
timestamps, but obviously ntpd needs to convert between the two. And it
(currently) uses a 32-bit *signed* quantity for the seconds, with the
value 0 in Jan 1970. This means that it too has a 136-year window, and a
range of ~ 1902..2038 - i.e. it doesn't "start" in 1970. There is
(currently) no issue with deciding what time a given value represents
though - the window is locked down to that single range.
I.e. bottom line to the OP: Upgrade ntpd and you should be fine until
2038. But at that point you will have to do something unless "additional
logic" has been put into ntpd - Unix time will likely be a 64-bit signed
quantity by then, but still with 0 in 1970...
--Per Hedeland
p...@hedeland.org
Danny Mayer
> Then perhaps the documentation needs to be updated! The 36 year "epoch"
> (if that's the proper term) has been discussed before on this
> newsgroup although not recently. Perhaps because it's rare for anyone
> to start ntpd with a clock that's off by 37 years! I think you may be
> the only person to report such a problem in the four years or so that
> I've been reading this newsgroup!
Can we at least use the right numbers? It was 34 years and now is 68
years. Calculate 2^31 seconds from 1-1-1970.
Danny
Garrett Wollman
>And just to hopefully dispel some myths about *that*, i.e. Unix/POSIX
>time representation: First of all it really has nothing to do with NTP
>timestamps, but obviously ntpd needs to convert between the two. And it
>(currently) uses a 32-bit *signed* quantity for the seconds, with the
>value 0 in Jan 1970.
Depends on your operating system and platform. Viz.:
wollman@khavrinen(5)$ cat >foo.c
#include <stdio.h>
#include <time.h>
int
main(void)
{
printf("sizeof(time_t) is %zu characters\n", sizeof(time_t));
}
wollman@khavrinen(6)$ make foo
cc -O -pipe foo.c -o foo
wollman@khavrinen(7)$ ./foo
sizeof(time_t) is 8 characters
wollman@khavrinen(10)$ uname -sm
FreeBSD amd64
(As it turns out, FreeBSD is Y2038-ready on all 64-bit platforms.
Other operating systems will vary, and there may be other limitations
and sanity checks that prevent you from setting a particular date in
the far past or future.)
-GAWollman
--
Garrett A. Wollman | The real tragedy of human existence is not that we are
wol...@csail.mit.edu| nasty by nature, but that a cruel structural asymmetry
Opinions not those | grants to rare events of meanness such power to shape
of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness
Richard B. gilbert
> Richard B. gilbert wrote:
>
>>Then perhaps the documentation needs to be updated! The 36 year "epoch"
>> (if that's the proper term) has been discussed before on this
>>newsgroup although not recently. Perhaps because it's rare for anyone
>>to start ntpd with a clock that's off by 37 years! I think you may be
>>the only person to report such a problem in the four years or so that
>>I've been reading this newsgroup!
>
>
> Can we at least use the right numbers? It was 34 years and now is 68
> years. Calculate 2^31 seconds from 1-1-1970.
>
Danny,
Please! I'm lucky to be able to count to twenty with my shoes on!
Trying to calculate the number of seconds elapsed from 1970 to now is
completely beyond me. If I got my computer to do it, I still wouldn't
know if the answer was right. Leap years+leap seconds. . . . .
Forget it.
I'd write 34 on a post-it and paste it on my monitor but it would
probably fall off by itself before I needed it again.
Danny Mayer
> Well, even if the code is not changed, it would be extremely helpful
> to document the actual behavior of ntpd -g.
>
> That way people know that a ballpark date adjustment
> is necessary before ntpd can do anything useful.
> Even embedded systems guys read man pages ....
Which would do you no good since we only distribute documentation in HTML.
Danny
Garrett Wollman
Danny Mayer <ma...@ntp.isc.org> wrote:
>Which would do you no good since we only distribute documentation in HTML.
Which is deeply and profoundly broken, but your choice, I suppose. It
does make the burden on everyone else quite a bit higher, to have to
maintain their own manual pages since the NTP developers do not see
fit to provide any.
Harlan Stenn
Garrett> Which is deeply and profoundly broken, but your choice, I suppose.
Dave's choice.
I am working on a way to automate the production of some of the
documentation in a variety of formats.
Garrett> It does make the burden on everyone else quite a bit higher, to
Garrett> have to maintain their own manual pages since the NTP developers do
Garrett> not see fit to provide any.
That's a bit harsh.
And I will reiterate my call for volunteers to help with this project.
H
David J Taylor
> Robert Dodier wrote:
>> Well, even if the code is not changed, it would be extremely helpful
>> to document the actual behavior of ntpd -g.
>>
>> That way people know that a ballpark date adjustment
>> is necessary before ntpd can do anything useful.
>> Even embedded systems guys read man pages ....
>
> Which would do you no good since we only distribute documentation in
> HTML.
>
> Danny
.. and thank goodness for that HTML!
David
Danny Mayer
> In article <4609C667...@ntp.isc.org>,
> Danny Mayer <ma...@ntp.isc.org> wrote:
>
>> Which would do you no good since we only distribute documentation in HTML.
>
> Which is deeply and profoundly broken, but your choice, I suppose. It
> does make the burden on everyone else quite a bit higher, to have to
> maintain their own manual pages since the NTP developers do not see
> fit to provide any.
>
Actually no, that was Dave's decision. He maintains all of the
documentation in HTML. In any case manpages are not deployable across
non-Unix operating systems. HTML today is usable across any O/S you care
to install it on and can be browsed remotely. There have been proposals
floated to provide converters to convert the docs to manpages for people
who insist on them but it's silly to insist that that's the best way to
deliver authorative documentation.
Danny
> -GAWollman
Richard B. gilbert
> In article <4609C667...@ntp.isc.org>,
> Danny Mayer <ma...@ntp.isc.org> wrote:
>
>
>>Which would do you no good since we only distribute documentation in HTML.
>
>
> Which is deeply and profoundly broken, but your choice, I suppose. It
> does make the burden on everyone else quite a bit higher, to have to
> maintain their own manual pages since the NTP developers do not see
> fit to provide any.
This is Unix centric thinking. Some operating systems; e.g. Windows,
VMS, and, perhaps, others do not have "man pages" or anything to read
them with!
HTML browsers are widely available. For those who don't, can't, or
won't have one, the HTML is formatted in such a way that it is possible
to read it as English text and ignore the HTML tags.
And, frankly, many man pages are almost unreadable anyway. They list
seven hundred switches and options without ever telling you how you
might accomplish the task at hand!
Uwe Klein
> And, frankly, many man pages are almost unreadable anyway.
or incomplete:
man xyznix
This is the help page for xyznix
options a
option b
this man page is not complete
consult the info page for the complete
description
/
unfortunately man info does not give enough
help to actually use the info command.
OK , you can escape to TkInfo, much better.
Nonetheless do i find the gnu attitude in this context pompous.
> They list seven hundred switches and options without ever telling you how you
> might accomplish the task at hand!
Thats what (Mini)HowTos are there for.
uwe
Richard B. gilbert
Mini HowTos?? Where might I find those? (First I've heard of such a
thing!)
Uwe Klein
> Mini HowTos?? Where might I find those? (First I've heard of such a
> thing!)
HowTos usually are a walkthrough for using some
select feature or programm.
With most Linux Distros there is a bunch of them included.
( or it is a package you can install, same as with "all manpages"
locate -i howto on my SuSE 9.3 finds me about 4000 files.)
http://www.faqs.org/docs/minis1.html
There is one for clock/ntp:
http://www.faqs.org/docs/Linux-mini/Clock.html
>
A good topics for a MiniHowTow would be
What can ntpd do for me
How to set up an isolated synced cluster
( and why you usually don't want it )
...............
uwe
David J Taylor
[]
> HowTos usually are a walkthrough for using some
> select feature or programm.
>
> With most Linux Distros there is a bunch of them included.
> ( or it is a package you can install, same as with "all manpages"
> locate -i howto on my SuSE 9.3 finds me about 4000 files.)
>
> http://www.faqs.org/docs/minis1.html
>
> There is one for clock/ntp:
> http://www.faqs.org/docs/Linux-mini/Clock.html
>>
>
> A good topics for a MiniHowTow would be
>
> What can ntpd do for me
>
> How to set up an isolated synced cluster
> ( and why you usually don't want it )
>
> ...............
>
>
>
> uwe
.. and isn't that already available on the Web? The wiki?
David
Moe Trin
<fsaqd4-...@robert.houseofmax.de>, Uwe Klein wrote:
>With most Linux Distros there is a bunch of them included.
>( or it is a package you can install, same as with "all manpages"
That depends on the distribution. You can simply go to any sunsite mirror
and grab the tarball (this is in http://ibiblio.org/pub/linux/docs/HOWTO/
-rw-rw-r-- 1 gferg ldp 8844582 Mar 29 09:01 Linux-HOWTOs-20070329.tar.gz
-rw-rw-r-- 1 gferg ldp 7078076 Mar 29 09:01 Linux-HOWTOs-20070329.tar.bz2
lrwxrwxrwx 1 gferg ldp 29 Mar 29 09:02 Linux-HOWTOs.tar.bz2 ->
Linux-HOWTOs-20070329.tar.bz2
lrwxrwxrwx 1 gferg ldp 28 Mar 29 09:02 Linux-HOWTOs.tar.gz ->
Linux-HOWTOs-20070329.tar.gz
>locate -i howto on my SuSE 9.3 finds me about 4000 files.)
No idea why - there are only about 450 documents, a little over 3.8 million
words, or just under 690000 lines (call it 11500 pages of text). You may
have multiple print formats and multiple languages. Most distributions are
rather lax at keeping the HOWTO package up to date - two years ago, they
were being updated or re-written such that a third of the documents were
less than six months old. Currently, only 20 are less than 6 months old.
>There is one for clock/ntp:
>http://www.faqs.org/docs/Linux-mini/Clock.html
* Clock, The Clock Mini-HOWTO
Updated: Nov 2000. How to set and keep your computer's clock on time.
A bit on the old side.
>A good topics for a MiniHowTow would be
>
>What can ntpd do for me
* TimePrecision-HOWTO, Managing Accurate Date and Time HOWTO
Updated: Nov 2005. Explains the time mechanisms on Linux, what are time
zones, and precision with NTP.
Like that?
>How to set up an isolated synced cluster
> ( and why you usually don't want it )
A bit ambiguous
4.2.3. Clustering
* Beowulf-HOWTO, Beowulf HOWTO
Updated: Jan 2005. Describes step by step instructions on building a
Beowulf cluster. This is a Red Hat and LAM specific version of this
document.
* Mock-Mainframe, The Mock Mainframe Mini-HOWTO
Updated: Oct 2005. A brief description of a standard way to set up and
work with a computer network for a small group of people that is
inexpensive to build, easy to administer, and relatively safe.
Probably not what you were referring to. ;-)
Old guy
Robert Dodier
> Robert Dodier wrote:
> > Well, even if the code is not changed, it would be extremely helpful
> > to document the actual behavior of ntpd -g.
>
> > That way people know that a ballpark date adjustment
> > is necessary before ntpd can do anything useful.
> > Even embedded systems guys read man pages ....
>
> Which would do you no good since we only distribute documentation in HTML.
No, that's not so. It would indeed help. It would help to fix the HTML
documentation because the man page which I read was derived by
some 3rd party from the HTML.
I did read the HTML page as well, and the relevant information about
the behavior of ntpd -g is not present there. I just want it to appear
somewhere in the ntp documentation. Other people seem to have
an axe to grind about document formats. I don't care about that.
FWIW
Robert Dodier
Per Hedeland
I don't know if you read all the posts that your query triggered, but we
already established that the 34-year limit was a bug in older versions
of ntpd, now fixed such that the limit is the 68 years inherent in the
precision of NTP timestamps, so the documentation obviously can't be
changed to say that there is a 34-year problem - maybe it could say that
there used to be one though...
--Per Hedeland
p...@hedeland.org