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?
When the box was off, all questions of accurate ntp tracking are moot.
ntp is designed around the idea that every second happens but from your
machine's point of view they didn't happen since it was powered down.
I would go the really simple route and force ntpdate to run once during
boot up before ntpd is started, thereby avoiding the entire issue.
Sometimes correctness really doesn't matter, this looks like one of those.
alan
