[ntp:questions] ntpdate.c unsafe buffer write

Harlan Stenn stenn at ntp.org
Sun Feb 10 22:47:00 UTC 2008

>>> In article <47af716b$0$513$5a6aecb4 at news.aaisp.net.uk>, David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

David> Harlan Stenn wrote:
>> Why would ntpd be exiting during a warm start?

David> Because we are discussing using it with the -q option.  If you just
David> use -g, it will take a lot longer to converge within a few
David> milliseconds, as it will not slew at the maximum rate.  If you use
David> -q, you need to force a step if you want fast convergence.

I still maintain you are barking up the wrong tree.

In terms of the behavior model of ntp, "state 4" is as good as it gets.  You
are in the right ballpark.

If you want something else, something you consider "better" than state 4,
please make a case for this and lobby for it.

>> For the case I'm describing the startup script sequence is to fire up
>> 'ntpd -g' early.  If there are applications that need the system clock to
>> be on-track stable (even if a wiggle is being dealt with), that's 'state
>> 4', and running 'ntp-wait' before starting those services is, to the best
>> of my knowledge, all that is required.

David> State 4 means within 128ms and using the normal control loop, which
David> has a time constant of around an hour.

OK, and so what?

Is State 4 insufficient for your needs, or are you just splitting hairs?

David> For a cold start, it won't reach state 4 for a further 900 seconds
David> after first priming the clock filter.

>> If the system has a good drift file, I disagree with you.

David> The definition of cold start is that there is no drift file.

OK, now I know what the definitions are.

I don't recall offhand the expected time to hit state 4 without a drift

1) This should not be the ordinary case
2) How does this have any bearing on the ntpdate -b discussion?

>> And what is the big deal with using different config files?  The config
>> file mechanism has "include" capability so it is trivial to to easily
>> maintain common 'base' configuration with customizations for separate
>> start/run phases.

David> You are now talking about using -q.  The difficulty is that people
David> have enough trouble getting the run phase config file right.

I mention it because it's what you seem to be insisting on talking about.

I was providing a way to address the problems you describe with the (IMO
bad) mechanism (-q) under discussion.

>> But the bigger problem is why are you insisting on separate start/run
>> phases?  This has not been "best practice" for quite a while, and if you
>> insist on using this method you will be running in to the exact problems
>> you are describing.

>> No, the best advice is to understand why you have been using ntpdate -b
>> so far and understand the pros/cons of the new choices.

David> We are talking about system managers and package creators, neither of
David> which have much time to study the details.

Blessed are those who get what they deserve.

These are the same folks who must get ssh configurations and various other
network configurations working.

If the stock things work well enough for folks, great.

If folks have suggestions for improvements I welcome them.

If folks want something different I invite them to make a case for it.
Please remember the scope and complexity of the problem case.  It's much
easier to have a simpler solution if one is prepared to ignore certain
problems.  Another case in this point is Maildir.

If somebody is in the situation where they know they have specific
requirements for time, they are in the situation where they have enough
altitude on their requirements to know the costs/benefits of what is
involved in getting there.

Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!

More information about the questions mailing list