On Fri, 22 Mar 2002 18:47:02 EST, Dave Baker writes: >> Ok, it lost it's NVRAM again, but here comes the (for me) confusing >> part: <...> >> Any hints on how I could reliably fix that? I can set the time to >> something closer to reality, then ntpdate works, but that seems >> especially ugly if done in an init-script. >My interim solution. > >On shutdown, I have an init script to just 'touch /some/filename' >On bootup, I set the system date to the timestamp of that file, then run >ntpdate, then run ntpd. 'tis a neat idea, no question. But a solution which would fix the actual problem would be nicer ;) I'll hack that in, anyway. >I think ntp has a safety check that prevents it from leaping the system >clock by more than so many years (makes sense really), so getting it set >close enough in this way was good enough for me. Uh, 1968->1934 ;-? The default, where ntp complains and exits, is 1.000 seconds in any direction. That's why one usually uses ntpdate to set some approximate (for ntp values of "approximate". $deity, I hope noone ever gets that paranoid in Real Life ;) ) prior to starting ntpd. I guess the actual problem is the negative ctime, but I've no clue whatsoever on how to battle against _that_ one other than finally spending real money (which I'd like to avoid at (arhemm) "any cost" ;) ). cheers, &rw -- -- "One vi to rule them all, one vi to bind them, one vi to bring them all -- and in the darkness bind them, in the land of BOFHnet where the shadows -- lie." "Which vi would that be, then?" -- Anthony de Boer and Tony Finch
Attachment:
signature.ng
Description: PGP signature