On 03/17/2016 11:31 PM, Mick wrote:
On Friday 18 Mar 2016 06:01:17 Bill Kenworthy wrote:
On 18/03/16 05:59, Bill Kenworthy wrote:
On 18/03/16 05:14, Alan McKinnon wrote:
On 17/03/2016 22:02, Håkon Alstadheim wrote:
On 03/17/2016 02:03 PM, Bill Kenworthy wrote:
On 17/03/16 20:26, Alan McKinnon wrote:
On 17/03/2016 08:50, Håkon Alstadheim wrote:
I have a server SUPPOSED to be running 24/7, but every once in a
while
during a prolonged absence the box will go down. The Real Time Clock
will drift, and in the rush to get the box up again I let everything
boot up automatically and get both wrong time on the main systems,
and
different times on the various systems.
My setup has a main server which does NTP, but with no direct link to
the outside. Router&firewall /have/ to be booted booted later (dumb
setup, don't ask), after which I can finally get correct time from
NTP.
NTP initiates "11 minute mode", which makes /etc/adjtime useless as
far
as I understand. Anybody have a /correct/ way to account for RTC
drift
on a box running ntpd? Right now I have a ---file in
/etc/cron.d/time-bad like so:
* * * * * root adjtimex -S 5 >/dev/null 2>&1 </dev/null
---
Combined with an old-fashioned setup for hwclock during boot and
shutdown. This feels really wrong, and I have no idea what I am
doing.
TLDR: Anybody have a /correct/ way to account for RTC drift on a box
running ntpd?
Have you looked at adjtimex ... its in portage
From the man page ...
"For a standalone or intermittently connected machine, where it’s not
ossible to run ntpd, you may use adjtimex instead to correct the sys-tem
clock for systematic drift.
There are several ways to estimate the drift rate. If your
computer can be connected to the net, you might run ntpd for at least
several hours and run "adjtimex --print" to learn what values of tick
and freq it settled on. Alternately, you could estimate values using as
a reference the CMOS clock (see the --compare and --adjust switches),
another host (see --host and --review), or some other source of time
(see --watch and --review). You could then add a line to rc.local
invoking adjtimex, or configure /etc/init.d/adjtimex or
/etc/default/adjtimex, to set those parameters each time you reboot."
Used it at one time for dialup which approximates your condition.
BillK
forget it ... I forgot that's where you started from ... must be getting
old :(
Nobody mentioned net-misc/chrony. Would it be more appropriate for this use
case?
This is looking really good. I never considered chrony since I scrapped
my modems ~15 years ago, but chrony has these things going for it:
- Good documentation in info format
- It acknowleges the existence of the rtc
- Allows turning OFF system -> rtc updates
- Keeps its own drift files, which I believe watches both rtc and system
clock drift.
I'll run chrony with "-r -s" , with "rtcfile" and without "rtcsync".
My hopes are high. :-D .