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

[Tore Anderson]

* Scott James Remnant

> Matt's asked me to jump in here to explain the Ubuntu changes, and our
> long-term plan for such thing; as there seems to be a little confusion
> and/or argument on this topic.

  Thanks, I appreciate it.

> Our reason for moving this to an if-up.d script is because we're
> increasingly relying on udev to drive the hardware parts of our boot
> sequence; this meant that there was no point in the SysV boot sequence
> where "networking was up", so no point to run the ntpdate script.
> 
> Moving to an if-up.d script meant that the clock would be adjusted
> during boot when the each ethernet card came up; the first not being
> sufficient as that one might not actually get an IP.

  I know, but see below for comments.

> This isn't ideal either, as now ntpdate gets run every time you fiddle
> with an interface.  Our preferred solution is to use upstart to manage
> the ntpdate task, and don't run it once it has succeeded at least
> once.

  I'm not familiar with upstart, I'm afraid, so I can't comment on
 that.  

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

  I think it would be reasonable to assume that this is a concern
 primarily for server systems that are probably always connected anyway,
 and thus it would be okay to step the clock later if there was no
 network at boot (even though this can cause trouble for desktop systems
 too in some cases, see #364288 for an example).  In any case, though,
 it should not be stepped unless deemed necessary by ntpd[ate] because
 of a large offset.  So if there's a chance of ntpdate being run after
 bootup, it shouldn't use "-b".  Default behaviour is okay.  I've cooled
 down a bit now, so I'll moderate myself a bit about demanding -B.  :-)

* Tore Anderson

> If no NTP server is available at bootup, well, then you'll just have
> to wait for a network connection and possibly step the time then.

* Scott James Remnant
 
> That's what we're trying to do with the ntpdate script.

  My opinion is that ntpd is better used for this.  When I run ntpd, I
 expect it to do so if necessary.  When I run "ifup" I expect it to do
 just that - bring an interface up.  Not meddle around with system time,
 or do any other things unrelated to bringing the interface up.

  I'm a sysadmin.  I don't like surprises.  Having my clock stepped on
 ifup is definetively a surprise, and a nasty one too (offlined half our
 office).

  Besides, using ntpd for this would handle the situation where a route
 to the NTP server is provided by something else than ifupdown, such as
 a routing service (my case), a PPP[oE] daemon (common xDSL/GSM setups
 here in Norway at least), and probably other situations too.  Finally,
 ntpd is more accurate than ntpdate - at least it says so in the manual
 page.

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

  So my recommendation would be to call ntpdate on bootup after udev was
 started (maybe using Required-Start: $network instead if that's
 working).  If it failed, oh well, start ntpd -g anyway and it'll
 synchronise when/if the time server becomes reachable at some later
 point.  And most importantly - it will not step unless it feels it
 needs to do so because of a large offset, and paranoid me, running
 services I know depend on clock sanity, can add -x to the the ntp-
 server init script and be safe no stepping will occur after initial
 boot.

  If you insist on coupling this to ifup, though:

  Check to see if the ifup is related to time server reachability at all
 (in my case it wasn't, which made the whole ordeal feel even more
 pointless).  In pre-up.d do "ip route get <time server>", see if
 there's already a route there, and if so just skip syncing (or at
 least, drop -b) in post-up.d.

  Also you could make the script see if /etc/nologin is present, if not,
 it's likely not running at system bootup, skip it (or at least, drop
 -b).  Heck, even checking that system uptime is <5 minutes or something
 would be a pragmatic (though rather ugly) approach.  :-)

Regards
-- 
Tore Anderson