[pkg-ntp-maintainers] Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start

[Scott James Remnant]

On Thu, 2006-12-14 at 13:07 +0100, Tore Anderson wrote:

> * Scott James Remnant
> 
> > We use "-b" because it was what was suggested in the manual page:
> > 
> >   -b  Force  the  time  to  be stepped using the settimeofday() system
> >       call, rather than slewed (default) using  the  adjtime()  system
> >       call. This option should be used when called from a startup file
> >       at boot time.
> > 
> > The if-up.d ntpdate script is intended to "set the clock at boot time",
> > once the first interface with a reachable ntp server has come up.
> 
>   But right now it does not check if any of this is true, which is my
>  main grief here.  When the services are done being started (and I think
>  you'll have to assume they do during bootup), it is not safe to step
>  the clock.
> 
That is true, in practice this hasn't caused us many problems; but it is
noted as a bug we need to fix.  One of the principal differences between
Debian and Ubuntu is that we don't have the luxury of a long release
cycle, so sometimes the immediate bug is fixed leaving another "lesser"
bug in place to be fixed in a later release.


I'd actually argue that you wouldn't want to forcibly change the clock
once the first service is *starting*.  As soon as you have at least one
service running, it's arguably dangerous to slew the clock, and instead
we should always step it from there on.

If ntpdate is lucky enough to get run before the first service is
starting, there's no real harm in slewing it.

The trick is weighing up the odds; if it's slewed, it can harm servers;
but if it's stepped, desktop users will complain that their clock is
wrong on boot, and takes a long time to get itself right again.

Our primary reason for running it at all is dealing with
desktops/laptops with broken hardware clocks.

Servers will almost certainly be running ntpd if they care about the
time.

> > Given the above, how would you recommend we sync the clock during boot
> > if no clock adjustments would be preferred?
> 
>   Note "gratuitous".  I realise that's a matter of personal opinion, but
>  I agree both with you and ntpdate's manual page that stepping on bootup
>  is fine.  On the other hand, I think stepping at an arbitrary time
>  after the system is up and running is just asking for trouble, at least
>  for production systems (and again, it might be for desktops too).  If I
>  understand you correctly you/Ubuntu think this is an acceptable trade-
>  off and I obviously disagree with you on that.
> 
We think it's a bug in our current install; but one that is less than
the previous bug of the clock being not changed at all.

Debian certainly shouldn't follow suit, unless they're also happy to
have an open bug that the clock is slewed whenever a network interface
comes up.

>   So my recommendation would be to call ntpdate on bootup after udev was
>  started (maybe using Required-Start: $network instead if that's
>  working). 
> 
The udev daemon being started doesn't have any bearing on whether a
network interface is up or not; network interfaces come up at their own
leisure.

I believe there's a fair amount of resistance to running ntpd in our
default installation.

> If you insist on coupling this to ifup, though:
> 
Our plan for feisty is to run ntpdate as an upstart job (an "init
script" in SysV terms), the state in which it can be run defined as a
point after a network interface has come up, but before the boot
sequence has finished.

If someone needs a clock syncing afterwards, we can either require ntpd;
or use -B.

Scott
-- 
Scott James Remnant
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-ntp-maintainers/attachments/20061214/9c027875/attachment-0001.pgp