1 |
On 17/03/2016 22:02, Håkon Alstadheim wrote: |
2 |
> On 03/17/2016 02:03 PM, Bill Kenworthy wrote: |
3 |
>> On 17/03/16 20:26, Alan McKinnon wrote: |
4 |
>>> On 17/03/2016 08:50, Håkon Alstadheim wrote: |
5 |
>>>> I have a server SUPPOSED to be running 24/7, but every once in a while |
6 |
>>>> during a prolonged absence the box will go down. The Real Time Clock |
7 |
>>>> will drift, and in the rush to get the box up again I let everything |
8 |
>>>> boot up automatically and get both wrong time on the main systems, and |
9 |
>>>> different times on the various systems. |
10 |
>>>> |
11 |
>>>> My setup has a main server which does NTP, but with no direct link to |
12 |
>>>> the outside. Router&firewall /have/ to be booted booted later (dumb |
13 |
>>>> setup, don't ask), after which I can finally get correct time from NTP. |
14 |
>>>> |
15 |
>>>> NTP initiates "11 minute mode", which makes /etc/adjtime useless as far |
16 |
>>>> as I understand. Anybody have a /correct/ way to account for RTC drift |
17 |
>>>> on a box running ntpd? Right now I have a ---file in |
18 |
>>>> /etc/cron.d/time-bad like so: |
19 |
>>>> * * * * * root adjtimex -S 5 >/dev/null 2>&1 </dev/null |
20 |
>>>> --- |
21 |
>>>> |
22 |
>>>> Combined with an old-fashioned setup for hwclock during boot and |
23 |
>>>> shutdown. This feels really wrong, and I have no idea what I am doing. |
24 |
>>>> |
25 |
>>>> TLDR: Anybody have a /correct/ way to account for RTC drift on a box |
26 |
>>>> running ntpd? |
27 |
>>>> |
28 |
>>>> |
29 |
>>> |
30 |
>>> When the box was off, all questions of accurate ntp tracking are moot. |
31 |
>>> ntp is designed around the idea that every second happens but from your |
32 |
>>> machine's point of view they didn't happen since it was powered down. |
33 |
>>> |
34 |
>>> I would go the really simple route and force ntpdate to run once during |
35 |
>>> boot up before ntpd is started, thereby avoiding the entire issue. |
36 |
> Why can't I have proper drift information for my RTC ("bios clock") ? |
37 |
> The old way ( where "system-time as set by ntp" minus "RTC time" |
38 |
> gives "drift-value" written to /etc/adjtime ) used to work perfectly |
39 |
> for me for several years. Is there no canonical way of getting that |
40 |
> these days? |
41 |
> |
42 |
> My problem is that my WAN connection can not be brought up until well |
43 |
> after the main server is up (stupid I know, but rearranging things |
44 |
> entails a major overhaul). Thus a bios clock without drift information |
45 |
> gives me a choice between ntpdate (which messes up my logs) and ntp with |
46 |
> incremental adjustments (which might leave clocks wrong for several days). |
47 |
> |
48 |
> I really need the logs to be on the same clock for all systems. Don't |
49 |
> ask, just assume I know why it's called bleeding edge . I also really |
50 |
> need sub-minute accuracy on all clocks. I suppose I should try running |
51 |
> ntpdate on everything once the WAN connection is up, just to see how bad |
52 |
> the mess is. |
53 |
|
54 |
|
55 |
I think your answer will be "the mess will be horribly bad". |
56 |
|
57 |
Now that I understand your problem better, I don't know how to solve it. |
58 |
If man pages don't provide a solution (and there must be a way to do it |
59 |
surely) then James' idea of a cheap external time source sounds good. |
60 |
|
61 |
On time sources, for the life of me I cannot understand why those in |
62 |
computers suck so badly. The name-no brand one on my wrist, costing 30 |
63 |
bucks from a dodgy Chinese dude on the street corner, is easily accurate |
64 |
to a second a month. It gets bumped, whacked a lot, immersed in water |
65 |
frequently and subjected to temperatures sub-zero up to 40 deg C + in |
66 |
direct African sunlight (hot enough to damage LCDs and make them bleed). |
67 |
And it stays about a second a month, despite being cheap junk and |
68 |
running off a shitty battery. |
69 |
|
70 |
So why are the ones in my computer about as accurate as a sundial |
71 |
without a reference? Always wondered about that. |
72 |
|
73 |
-- |
74 |
Alan McKinnon |
75 |
alan.mckinnon@×××××.com |