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

[Victor Lowther]

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.

> > 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.

> --
> Dan
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019