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

Tore Anderson tore at debian.org
Fri Dec 15 15:18:21 CET 2006


* Scott James Remnant

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

  Say what?!  I hope you've just mixed up the terms here...

    "slew" -> adjtime() -> safe, clock will never leap
    "step" -> settimeofday() -> unsafe, clock will leap [back in time]

  I'll read the rest of your email assuming you exchanged those two.

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

  Yes.  That is exactly the role of the ntpdate program.  Get the clock
 into a reasonably correct state before services have begun starting,
 and ntpd will take it from there and keep it in sync.

  Without the initial ntpdate call you risk that ntpd will step after
 five minutes of uptime, because ntpd won't do anything at all before it
 has finished electing a syspeer and so on, and that takes a few
 minutes.  In those minutes a lot of services have probably have
 started, and when ntpd finally realises it wants to step, and does, Bad
 Things might happen.

  Therefore I want both ntpdate and ntpd in a server.

> 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.
>
> [...]
> 
> I believe there's a fair amount of resistance to running ntpd in our
> default installation.

  What I installed was a server install.  I got certainly got ntpdate
 with the ifup script (can't quite remember if ntpd was there after the
 install, but I guess not based on what you're writing above).  I also
 agree servers are best served by ntpd, so it is strange to hear there's
 resistance against including it in the default installation..?  Also
 ntpdate's documentation states pretty clearly it is no replacement for
 ntpd at all.

  Desktops are another matter.  I care most about the servers, as I've
 got probably two or three hundred times as many of those than I do
 desktops, so I know much less about desktops and what the desktop users
 in general want.  :-)  That said, I don't think the "always step"
 policy you have (i.e. ntpdate -b) is good there either.  If you run
 ntpdate without any arguments it will step, but only if the offset is
 >128ms.  According to its documentation, anyway.  Will really a user
 complain about the clock being wrong when it's way less then a second
 wrong?

  (Actually, I see now that the manual page is self-contradictory,
 it states elsewhere that the step treshold is 0.5 seconds.  But I would
 think that's insignificant anyway.)

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

  I actually submitted a bug to Launchpad about this and had it closed
 because it was allegedly fixed in the latest release.  I didn't verify
 that myself, though...  Maybe I should.  I didn't find an open bug
 about it either.  Do you have a link?

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

  It should be run after udev because I would assume it is useless to
 even attempt it before.  If it still was unable to sync the time
 because it had no connectivity to the NTP server, well, it failed the
 one shot it did have and that's that.  I see no harm in attempting to
 run ntpdate just as we're switching to the multiuser runlevel, there's
 nothing to lose from failure and plenty to gain from success.

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

  This sounds very good to me, it would certainly take ntpdate off my
 blacklist.  :-)

Regards
-- 
Tore Anderson





More information about the pkg-ntp-maintainers mailing list