NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
NTP Startup "step" choices
is started an offset correction may need to be applied. How that is done depends on the operational state of the machine.
Note that NTF's General Timestamp API should obviate the need for this level of process, as it has a way to provide for monotonic time even in the face of backward time adjustments.
Related Topics: Bug #2763
We should soon be able to put the following information into a table.
Some people like to set the time before starting
. Harlan would love to understand why this is needed or desirable.
If one does
set the time before starting
it should probably/always be done with a step. Otherwise there is a good chance that a small offset correction will not completely apply before
starts and that correction will be lost.
When a machine boots,
has the expectation that no time-critical services are yet running. We can "step" any needed time adjustments.
will step any offset correction greater than 128 milliseconds, and slew these smaller corrections. Since
applies corrections at the rate of 500ppm, that means a 128 millisecond correction will take 256 seconds (4 minutes and 16 seconds) to complete.
Generally, this is a non-issue for most situations. But if you have a Stratum 1 server and want it to be serving accurate time at the 10 microsecond level as soon as possible, you don't want to wait up to several minutes' time to see your offset get down to that level.
We note that there are systems out there where the time cannot be set this precisely, and there could also be a noticeable amount of jitter when setting the time. This could well be true, and the question is: Is there any harm in our attempt to precisely set the initial time, or is it just not very useful on some machines?
The bottom line is there would seem to be no harm in stepping all cold-start corrections.
ntpd -g ...
at cold-start, done as early as possible in the boot sequence, as
says "accept an arbitrary offset adjustment on the very first time correction." However
does not currently make any statement about "step/slew" of that initial correction.
- I proposed a new command line option -G which controls whether the initial offset should be adjusted with a step even when this offset is smaller than the step threshold (128ms). After the initial correction, everything should continue as in the current ntpd version (step/slew decision based on step threshold). -- HeikoGerstung - 30 Mar 2015
is restarted on a box that is already up and running where there are applications running where applications that require monotonic time are running we would want no backward time steps.
- The question I have is: do we want ntpd to automatically recognize whether it is performing a warm start or cold start ? If not (I assume this is something that could be handled in a rc script), I would think that ntd should not be started using -g and -G in a warm start situation. We should probably also add a way to tell ntpd to not step backwards and recommend using that possibility (e.g. another commandline option) for warm start scenarios. -- HeikoGerstung - 30 Mar 2015
When the system clock is very wrong
threshold, which defaults to 1000 seconds. This means that if
sees that the time is off by more than this amount it will log an error and exit, because something is Seriously Wrong.
By default, this will also be checked when
is first started. So if the clock is "way" off, unless there is a way to override this check
will not even start if the time is off by more than this value.
overrides this check.
The intent is to quickly get the attention of a human in case of a problem of this magnitude with the clock.
There are conflicting problems here.
On the one hand, we want to be alerted if the clock is badly off, and in that case
will exit because it doesn't want to make anything worse, and it doesn't want to be "in your way" when you try and diagnose and repair the problem.
On the other hand, we want to be able to quickly understand any underlying problem (if possible) and then get the system clock operating correctly again as soon as possible.
For me there are two different scenarios: a) the clock is badly off at startup (cold start) which can be caused by a bad CMOS clock or the fact that there is no RTC at all. OR b) the clock is badly off during normal operation, which in 99% of all cases I experienced was caused by a human setting the time manually to test whether ntp corrects the offset or not. While I see that a) is something that we should be able to take care of, b) is something that is caused by a lack of knowledge how ntpd works.
As far as I can see, ntpd covers the two situations correctly with the -g switch. On most NTP clients there is an RTC or some other way to get an idea of the current time before NTP is started. Therefore I currently see no need to change the behavior of ntpd (see below for a discussion whether the standard behavior of ntpd should imply -g).
Should startup always imply
is starting, should it always imply
and should it just log its initial correction, perhaps at a higher severity level if the adjustment is large?
- I do not think so. I see no huge benefit in changing this for a future version of ntpd. The -g switch has been widely adopted and is in use on a huuuge number of machines. Those who do not use it may have a good reason for this. Although I appreciate the approach to choose the default behavior to reflect what most people want, I appreciate the concept of backwards compatibility even more. -- HeikoGerstung - 30 Mar 2015