Bug#396937: [pkg-ntp-maintainers] Bug#396937: Backgrounded ntpdate from ifup races with hwclock

[Kurt Roeckx]

On Sat, Nov 04, 2006 at 10:32:13AM +0100, Andre Beck wrote:
> > 
> > ntpdate should never adjust the clock wrong by an hour, it should set it
> > correct.
> 
> Yep, but it does. I've had the proper loop in rc equipped with a date(1)
> call after every single init script, which revealed that time was wrong
> (by misinterpretation of the CMOS clock as UTC) in the whole boot process
> until S50hwclock.sh fixed it (which up to this is expected behavior). Both
> the output from that script (I even let it run -xv) and the date(1)
> immediately following it showed correct time.

I think you might be right.  ntpdate tries to find an offset between the
clock and what it thinks is the correct time, and then either steps or
adjusts it depending on how big the difference is.

So it finds an offset, gets the current clock, adds the offset, and sets
the new time.  If the clock is adjusted by something else between the
time it received the packets on which it based the offset and the time
it tries to set it, we have a problem.

> You may probably force this
> behavior easily by having one or two unreachable servers in the sequence
> first.

I think having unreachable servers at the end of the list is more likely
to cause problems.

> > I think your problem is that hwclock is started after ntpdate.
> 
> At least this is way too late for hwclock as we all agree - and running
> hwclock at a more proper time would likely fix it. What remains is the
> knowledge that ntpdate does something silly, though - when it runs over
> a macroscopic timescale due to unreachable servers or similar delays
> and something else changes the kernel clock during this time, it might
> end up offsetting the time *again*. Obviously it thinks it is the only
> tool that controls the clock, and everything works perfectly when it is.
> But now that it runs backgrounded, other tools might interfere. There is
> probably not only hwclock, but other time correction tools that use
> various sources might collide with it as well. IMO this should be fixed
> upstream, even when there cannot be a perfect fix (a small chance for
> a race condition will remain).

I think we should just make sure that nothing else can run at the same
time as ntpdate that wants to change the clock.

I think this should mean that it needs to run before us in the boot
process, it shouldn't run in the background.

Since it's started when an interface is brought up, I don't see how we
can run in the background and have some other script wait until we're
done.

Maybe we should ask some advice to someone else who knows more about
this, I'm just not sure who to ask.


Kurt