NTPd famously, by default, won't adjust the time if it's more than 1000s out, presuming as it does that there's a systemic problem with which it shouldn't get involved. This from
-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic
threshold, which is 1000 s by default. This option allows the time to be set to any value
without restriction; however, this can happen only once. If the threshold is exceeded after
that, ntpd will exit with a message to the system log. This option can be used with the -q
and -x options. See the tinker command for other options.
One problem is that BIOS clocks in the UK are often an hour out, because of misunderstandings about whether the BIOS is in UTC or summer time. I imagine the problem gets worse as your longitude from Greenwich increases.
So there is also a command
ntpdate, which wrenches the system clock into alignment with an NTP server, in an unsubtle manner that tends to upset a lot of running services. I believe it predates the addition of the
-g flag to ntpd.
Thus, for old-timers like myself, the full startup protocol for
ntpd involves the use of
ntpdate to forcibly sync the clock - on the basis that that's safest to do when the system starts up - followed by starting
ntpd to keep it there.
/etc/ntp/step-tickers controls which server is used to do the
ntpdate. I usually list one of my
ntp.conf servers in there.
To further confuse the matter, the
ntpdate startup script on CentOS6 will look in
ntp.conf for a startup ticker if one isn't listed in
step-tickers. So whilst it is certainly good practice to make sure that
ntpd won't be left high and dry (trying to sync a system clock that's too far out), between modern startup scripts and the
-g flag to
step-tickers really is a historical relic, with no necessary function in a modern distro. But I'm a historical relic, too, and so I continue to use it.