I have created a FreeBSD VM on Google cloud engine. The image is installed with ntpd configured and is running:

$service ntpd status
ntpd is running as pid 4950.

But date is in the future, the time goes too fast on the server.

Mon Feb 25 15:59:38 UTC 2019

UTC now is: Mon Feb 25 10:31:21 UTC 2019

I've tried to restart the ntpd service:

$service ntpd restart

without any luck. I found a discussion here: https://forums.freebsd.org/threads/the-system-clock-is-falling-behind.61450/. I need a drift file, so I added one:

$echo "0" > /var/db/ntpd.drift

Then I stopped and started the ntpd service:

$service ntpd stop
$service ntpd start

Now the time is correct. But I'm a bit lost was it the hard stop/start or the driftfile which solved the issue.


To sum up the problem: The time one the server goes too fast. The ntpd service is not correcting the issue, only when I restart the service. From my naive eyes it seems a second on the VM is a bit shorter than a real second.

  • you need to press the turbo button 🤦🏻‍♂️ – JurajB Jan 23 at 3:53

Put this line into the rc.conf. Time will be synced when you start the system and/or when you (re)start ntpd.


This parameter causes "ntpd" to start with option "-g" (see /etc/rc.d/ntpd), (see man ntpd)

-g, --panicgate. Allow the first adjustment to be Big. This option may appear an unlimited number of times. 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 configuration file directive for other options.

To sync running system:

1) stop ntpd

# /etc/rc.d/ntpd stop
Stopping ntpd.

2) sync time

# ntpdate 2.freebsd.pool.ntp.org
25 Feb 13:58:42 ntpdate[78591]: adjust time server offset 0.003268 sec

3) start ntpd

# /etc/rc.d/ntpd start
Starting ntpd.

To answer your question

Was it the hard stop/start or the driftfile which solved the issue ?

It must have been the "hard stop/start". driftfile is used for fine-tuning the frequency of the clock. This can't explain the difference of 5 hours.

FWIW. See below my driftfile in FreeBSD at DO.

# cat /var/db/ntpd.drift 

# ps ax | grep ntpd
26681  -  Ss       22:51.54 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift
| improve this answer | |
  • Thanks for the reply! I got some more understand of the setup. But my time is still way too fast . After a couple of minutes time drifts ahead of multiple seconds! This is really weird? Like some internal second is too short.. – DNRN Feb 26 '19 at 8:25
  • Might be interesting to see the details. You might follow How to create a Minimal, Complete, and Verifiable example. – Vladimir Botka Feb 26 '19 at 9:16
  • I would like to give more details, but have no idea what to show? I tried to minify the question without removing the history, and sum up my problem in a concise question. – DNRN Feb 26 '19 at 10:37
  • It's up to you ntpd logging & debugging. – Vladimir Botka Feb 26 '19 at 13:40

While using ntpd and ntpdate will mitigate the issue, the time will continue to skew between updates. Also, the current GCE images for FreeBSD 12 are alreayd configured to sync to Google's time server, but the issue still remains. This is a known issue in FreeBSD 12 on Google Compute Engine.

Check GCE: significant clock drift - the solution for tweaks to correct this. Summarizing:




| improve this answer | |

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.