We sometimes have the problem that new servers have the wrong time in the bios, so there time can be off by a month.

When you suspend a VM in VMware and then unsuspend it, the time will be off too. Because NTP does not sync after a maximum offset, I am considering using tinker panic 0 in the /etc/ntp.conf.

What is the reason that there is a default maximum offset of 1000 seconds that causes NTP to stop syncing time? We are using Puppet to set up NTP, I am considering to make it set tinker panic 0 in the ntp.conf, so NTP will sync anyway. What are the disadvantages of doing this?


2 Answers 2


The cause for not syncing against a server whose time is so different is documented here: What happens if the Reference Time changes?

Ideally the reference time is the same everywhere in the world. Once synchronized, there should not be any unexpected changes between the clock of the operating system and the reference clock. Therefore, NTP has no special methods to handle the situation.

Instead, ntpd's reaction will depend on the offset between the local clock and the reference time. For a tiny offset ntpd will adjust the local clock as usual; for small and larger offsets, ntpd will reject the reference time for a while. In the latter case the operation system's clock will continue with the last corrections effective while the new reference time is being rejected. After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and ntpd will terminate itself, believing something very strange must have happened.

In my current NTP configuration, also controlled by puppet, I force the synchronization with the server, both in the ntp.conf file, using tinker panic, and in the daemon settings (/etc/sysconfig/ntpd), as described in the ntpd(8) manpage:

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

I do this because I can trust the NTP server I'm connecting to.

The relevant portion of the module that applies to the clients is as follows:

class ntp (

  $my_files = {
    'ntp.conf'      => {
      path    => '/etc/ntp.conf',
      content => template("ntp/ntp.conf.$template.erb"),
      selrole => 'object_r',
      seltype => 'net_conf_t',
      require => Package['ntp'], },
    'ntp-sysconfig' => {
      path    => '/etc/sysconfig/ntpd',
      source  => 'puppet:///modules/ntp/ntp-sysconfig',
      require => Package['ntp'], },

  $my_files_defaults = {
    ensure   => file,
    owner    => 'root',
    group    => 'root',
    mode     => '0644',
    selrange => 's0',
    selrole  => 'object_r',
    seltype  => 'etc_t',
    seluser  => 'system_u',

  create_resources(file, $my_files, $my_files_defaults)

  exec { 'ntp initial clock set':
    command     => '/usr/sbin/ntpd -g -q -u ntp:ntp',
    refreshonly => true,
    timeout     => '-1',
    subscribe   => File['/etc/ntp.conf'],


And the contents of the referenced files are:

$ cat devops/puppet/modules/ntp/files/ntp-sysconfig
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -a"


$ cat devops/puppet/modules/ntp/templates/ntp.conf.RedHat.erb
# HEADER: This file was autogenerated by puppet.
# HEADER: While it can still be managed manually, it
# HEADER: is definitely not recommended.
tinker panic 0
<% server.each do |ntpserver| -%>
server <%= ntpserver %> autokey
<% end -%>
server     # local clock
fudge stratum 10
driftfile /var/lib/ntp/drift
crypto pw hunter2
crypto randfile /dev/urandom
keysdir /etc/ntp

The hiera part is missing here, but you get the idea.


The worst-case example would be attacks on your LAN-facing GPS receiver, this has been proven possible and is why NTP in those cases rather "leaves" than break anything immediately. This kind of problem, or sudden software bugs were expected at NTP's design time, and also both can happen.

One protection mechanism in the algorithm is the detection of what they call a falseticker, but that can only detect some problems, mostly if a upstream clock sends a backward time all of a sudden.

If it's only about "wrong clock at start time":

  • you can use /etc/ntp/step-tickers (on RHEL*, Debian never got the idea). The step-tickers file takes one or more NTP servers to run an ntpdate against prior to starting ntpd itself.
  • alternatively (or in addition) there's the -g option for ntpd, which allows ugly offsets, but only when they're found at start.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.