Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?

[Håkon Alstadheim]

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?
>>>
>>>
>>
>> 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.
Why can't I have proper drift information for my RTC ("bios clock") ? 
The old way ( where  "system-time as set by ntp"  minus "RTC time"  
gives "drift-value" written to /etc/adjtime )   used to work perfectly 
for me for several years. Is there no canonical way of getting that 
these days?

My problem is that my WAN connection can not be brought up until well 
after the main server is up (stupid I know, but rearranging things 
entails a major overhaul). Thus a bios clock without drift information 
gives me a choice between ntpdate (which messes up my logs) and ntp with 
incremental adjustments (which might leave clocks wrong for several days).

I really need the logs to be on the same clock for all systems. Don't 
ask, just assume I know why it's called bleeding edge . I also really 
need sub-minute accuracy on all clocks. I suppose I should try running 
ntpdate on everything once the WAN connection is up, just to see how bad 
the mess is.


>> Sometimes correctness really doesn't matter, this looks like one of those.
>>
>>
>> alan
>>
> add a cheap gps setup as the reference clock to the server,
That sounds like a real option. I have an old Nokia N900 lying around 
with a broken usb-port, so I'd need to solder in a power lead. Any 
pointers for how to read time signal from the gps on a maemo system?
> or even
> better is a dedicated time server (either a real one or a raspberry
> pi/gps) on the network if you have internal connectivity.  Going super
> cheap, but not quite as accurate for me was an arduino and rtc on a
> bluetooth pan for when the network was down but I needed a reference (to
> power up the real server :).
>
>
> google "arduino time server" for plenty of options :)
>
This led me to finding some serial-port connected gps modules. 
Serial-ports I have, so this is sounding good. 35 to 40 euro for a gps 
device when hwclock and /etc/adjtime should give ballpark-correct time 
on boot makes me hate this though.

This reminds me one reason I need a valid time is my DVB-T TV-receiver 
card. It should be possible to find a clock source in the broadcast 
stream. I'll research that first, while I leave my "adjtime -S 5 " hack 
running, even though I still don't know if that makes any sense at all. 
At least now there is something different from "0.0000" in the 
driftvalue, which gives me some hope I'm on to something.