[ntp:questions] [ntp:hackers] ntpdate removal is coming

Harlan Stenn stenn at ntp.org
Wed Dec 7 20:40:28 UTC 2011


Marco wrote:
> Il 07/12/2011 08:30, Harlan Stenn ha scritto:
> >>> If anybody knows of any *good* reasons to set the clock before starting
> >>> > > ntpd, please speak up.
> >> > 
> >> > Indeed!
> >> > It is very handy to set the clock directly on system startup
> >> > (eg. when the external clock is lacking proper battery).
> >> > I've still got a bunch of system using it.

"ntpd ... -g ..." will work in this case.  There is no need to set the
time before running ntpd handle the case of a bad CMOS battery.

> >> > Oh, and of course its very handy for diagnostics.

ntpd and sntp should have at least the same level of diagnostic
ability.  If not, please open a bug report.

> > I'm not saying one should not set the clock on system startup.
> > 
> > I'm saying I'm not aware of good reasons to set the clock before
> > starting ntpd at system startup.
> 
> I still use ntpdate -q as a debugging tool.

Are the diagnostic capablilties of sntp or ntpd lacking in any way?

> But I have another case, as well.
> 
> I had a case at $PREVIOUS_EMPLOYER where we had to do exactly that, or
> more precisely: stop ntpd, run ntpdate, then start ntpd again.
> 
> We had a few faulty servers that, for some reason, kept setting the
> clock one or two hours backwards, depending if we had DST or not[*].
> Something was happening in the line that the system rebooted/started
> with proper time and timezone, then read the UTC time from the hardware
> clock as it was local time, and set it on the system. When ntpd started,
> it aborted since the machine appeared way off than the tolerated amount.

Then you were not using the -g flag to ntpd.

Use the -g flag and you will not need to set the time before running
ntpd.

If the time was being reset *after* ntpd was started then you have a
different problem and that bug is not with ntpd.  In this case:

- the -g option is still what you want
- you should report the problem upstream (hardware or distribution vendor)

Also note that in this case things like dovecot or database servers will
complain loudly and probably shut down, because they require monotonic
(only forward-moving) time.  If you are running those apps they will
need to be restarted as well.

> Of course we could dig down into the hairy configuration files of these
> boxes in order to open a case to either the hardware vendor, or to the
> distribution vendor. But we were pretty understaffed at the time; plus,
> keeping that server offline for the few hours needed to debug it was not
> an option, and we ended up with that patchy workaround.
> 
> That is why I'd happily keep ntpdate...

And there will be a shell script called "ntpdate" that will "do the
right thing" (somebody will have to decide if the local policy for the
script is "set the time ASAP" or "set the time Well"), but again, I'm
still not seeing that this is a *necessary* step.

H


More information about the questions mailing list