1 |
On 17/03/16 20:26, Alan McKinnon wrote: |
2 |
> On 17/03/2016 08:50, Håkon Alstadheim wrote: |
3 |
>> I have a server SUPPOSED to be running 24/7, but every once in a while |
4 |
>> during a prolonged absence the box will go down. The Real Time Clock |
5 |
>> will drift, and in the rush to get the box up again I let everything |
6 |
>> boot up automatically and get both wrong time on the main systems, and |
7 |
>> different times on the various systems. |
8 |
>> |
9 |
>> My setup has a main server which does NTP, but with no direct link to |
10 |
>> the outside. Router&firewall /have/ to be booted booted later (dumb |
11 |
>> setup, don't ask), after which I can finally get correct time from NTP. |
12 |
>> |
13 |
>> NTP initiates "11 minute mode", which makes /etc/adjtime useless as far |
14 |
>> as I understand. Anybody have a /correct/ way to account for RTC drift |
15 |
>> on a box running ntpd? Right now I have a ---file in |
16 |
>> /etc/cron.d/time-bad like so: |
17 |
>> * * * * * root adjtimex -S 5 >/dev/null 2>&1 </dev/null |
18 |
>> --- |
19 |
>> |
20 |
>> Combined with an old-fashioned setup for hwclock during boot and |
21 |
>> shutdown. This feels really wrong, and I have no idea what I am doing. |
22 |
>> |
23 |
>> TLDR: Anybody have a /correct/ way to account for RTC drift on a box |
24 |
>> running ntpd? |
25 |
>> |
26 |
>> |
27 |
> |
28 |
> |
29 |
> When the box was off, all questions of accurate ntp tracking are moot. |
30 |
> ntp is designed around the idea that every second happens but from your |
31 |
> machine's point of view they didn't happen since it was powered down. |
32 |
> |
33 |
> I would go the really simple route and force ntpdate to run once during |
34 |
> boot up before ntpd is started, thereby avoiding the entire issue. |
35 |
> Sometimes correctness really doesn't matter, this looks like one of those. |
36 |
> |
37 |
> |
38 |
> alan |
39 |
> |
40 |
|
41 |
add a cheap gps setup as the reference clock to the server, or even |
42 |
better is a dedicated time server (either a real one or a raspberry |
43 |
pi/gps) on the network if you have internal connectivity. Going super |
44 |
cheap, but not quite as accurate for me was an arduino and rtc on a |
45 |
bluetooth pan for when the network was down but I needed a reference (to |
46 |
power up the real server :). |
47 |
|
48 |
|
49 |
google "arduino time server" for plenty of options :) |
50 |
|
51 |
BillK |