[Pm-utils] [PATCH 8/8] pm-utils 1.2.3 proposed patches

[Dan Nicholson]

On Sun, Nov 30, 2008 at 10:54 AM, Victor Lowther
<victor.lowther at gmail.com> wrote:
> On Nov 30, 2008, at 10:42 AM, "Dan Nicholson" <dbn.lists at gmail.com> wrote:
>>
>> Yeah, go ahead and release. More releases can always be made later.
>> What would it take to find if 50ntpd can be removed? I personally
>> think it's a waste of time, but maybe I'm missing the real reason for
>> it's existence. Should I ask on the ntp list?
>
> Well, this code also seems to go all the way back to the initial checkin,
> and based on the commit log comments it is there to try and fix any clock
> drift the system may have experienced while asleep.
>
> If we had a way to just tell ntpd to sync at the next oppourtunity, this
> hook would be much less ugly. However, it seems that there is no such way,
> so restarting ntpd is the only option, aside from just letting sync
> according to its usual schedule.

If we assume that the clock has only drifted, and that it's not
completely out of sync, then I think it would be preferable to just
let ntpd sync on its own. According to ntp.conf, the default minimum
polling interval is 64 seconds. So, most likely you'd go 1 minute with
your clock drifted. I think that's acceptable. You can see what the
polling interval for your servers is with `ntpdc -c peers'. It would
be cool if ntpd polled immediately when the network came up, but I
don't know if it does that.

> Since we don't, it may be best to drop this hook, just let ntpd continue to
> sync according to its internal schedule, and consider getting networkmanager
> to kick ntpd for us whenever the internet is back up.

I think ultimately that this can only be handled correctly by the
system's networking subsystem since it actually knows when the network
is coming and going. For the common case of NM, it's a trivial
dispatcher script. That assumes that manually restarting ntpd is
necessary.

--
Dan