1 |
On Friday 18 Mar 2016 06:01:17 Bill Kenworthy wrote: |
2 |
> On 18/03/16 05:59, Bill Kenworthy wrote: |
3 |
> > On 18/03/16 05:14, Alan McKinnon wrote: |
4 |
> >> On 17/03/2016 22:02, Håkon Alstadheim wrote: |
5 |
> >>> On 03/17/2016 02:03 PM, Bill Kenworthy wrote: |
6 |
> >>>> On 17/03/16 20:26, Alan McKinnon wrote: |
7 |
> >>>>> On 17/03/2016 08:50, Håkon Alstadheim wrote: |
8 |
> >>>>>> I have a server SUPPOSED to be running 24/7, but every once in a |
9 |
> >>>>>> while |
10 |
> >>>>>> during a prolonged absence the box will go down. The Real Time Clock |
11 |
> >>>>>> will drift, and in the rush to get the box up again I let everything |
12 |
> >>>>>> boot up automatically and get both wrong time on the main systems, |
13 |
> >>>>>> and |
14 |
> >>>>>> different times on the various systems. |
15 |
> >>>>>> |
16 |
> >>>>>> My setup has a main server which does NTP, but with no direct link to |
17 |
> >>>>>> the outside. Router&firewall /have/ to be booted booted later (dumb |
18 |
> >>>>>> setup, don't ask), after which I can finally get correct time from |
19 |
> >>>>>> NTP. |
20 |
> >>>>>> |
21 |
> >>>>>> NTP initiates "11 minute mode", which makes /etc/adjtime useless as |
22 |
> >>>>>> far |
23 |
> >>>>>> as I understand. Anybody have a /correct/ way to account for RTC |
24 |
> >>>>>> drift |
25 |
> >>>>>> on a box running ntpd? Right now I have a ---file in |
26 |
> >>>>>> /etc/cron.d/time-bad like so: |
27 |
> >>>>>> * * * * * root adjtimex -S 5 >/dev/null 2>&1 </dev/null |
28 |
> >>>>>> --- |
29 |
> >>>>>> |
30 |
> >>>>>> Combined with an old-fashioned setup for hwclock during boot and |
31 |
> >>>>>> shutdown. This feels really wrong, and I have no idea what I am |
32 |
> >>>>>> doing. |
33 |
> >>>>>> |
34 |
> >>>>>> TLDR: Anybody have a /correct/ way to account for RTC drift on a box |
35 |
> >>>>>> running ntpd? |
36 |
> > |
37 |
> > Have you looked at adjtimex ... its in portage |
38 |
> > |
39 |
> > |
40 |
> > From the man page ... |
41 |
> > "For a standalone or intermittently connected machine, where it’s not |
42 |
> > ossible to run ntpd, you may use adjtimex instead to correct the sys-tem |
43 |
> > clock for systematic drift. |
44 |
> > |
45 |
> > There are several ways to estimate the drift rate. If your |
46 |
> > |
47 |
> > computer can be connected to the net, you might run ntpd for at least |
48 |
> > several hours and run "adjtimex --print" to learn what values of tick |
49 |
> > and freq it settled on. Alternately, you could estimate values using as |
50 |
> > a reference the CMOS clock (see the --compare and --adjust switches), |
51 |
> > another host (see --host and --review), or some other source of time |
52 |
> > (see --watch and --review). You could then add a line to rc.local |
53 |
> > invoking adjtimex, or configure /etc/init.d/adjtimex or |
54 |
> > /etc/default/adjtimex, to set those parameters each time you reboot." |
55 |
> > |
56 |
> > Used it at one time for dialup which approximates your condition. |
57 |
> > |
58 |
> > BillK |
59 |
> |
60 |
> forget it ... I forgot that's where you started from ... must be getting |
61 |
> old :( |
62 |
|
63 |
Nobody mentioned net-misc/chrony. Would it be more appropriate for this use |
64 |
case? |
65 |
|
66 |
-- |
67 |
Regards, |
68 |
Mick |