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

[Dan Nicholson]

On Sun, Nov 30, 2008 at 2:35 PM, Victor Lowther
<victor.lowther at gmail.com> wrote:
> On Sun, 2008-11-30 at 11:52 -0800, Dan Nicholson wrote:
>> 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.
>
> Well, the man page and the documentation do not list any sort of
> "refresh now" functionality, and the usual signals (HUP, USR1, USR2)
> appear to either do nothing or kill the daemon outright.

Yeah, I think the only actual "refresh now" method is to kill ntpd and
then run ntpdate or `ntpd -q', which will block until the clock is
synchronized. Just starting ntpd does not immediately sync, so
stopping and restarting ntpd provides no gain over just leaving it
running. However, if the distro's ntpd initscript syncs first via one
of the above methods, then I guess people lose that functionality.

I was also perusing the ntp-questions archives, and it doesn't appear
that there's any guarantee that ntpd will synchronize in a reasonable
amount of time.

https://lists.ntp.org/pipermail/questions/

>> > 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.
>
> According to my not at all rigorous testing, ntpd continues to operate
> just fine when the network interfaces appear and disappear.  I think we
> can safely get rid of this hook for now.

I'm gonna send a message to the ntp-questions list and see if I can
get a qualified person's opinion.

--
Dan