0

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.

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

[Update]

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.

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

2 Answers 2

3

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

ntpd_sync_on_start="YES"

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 62.197.207.182 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 
0.075

# 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
4
  • 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, 2019 at 8:25
  • Might be interesting to see the details. You might follow How to create a Minimal, Complete, and Verifiable example. Feb 26, 2019 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, 2019 at 10:37
  • It's up to you ntpd logging & debugging. Feb 26, 2019 at 13:40
0

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:

/boot/loader.conf:

machdep.disable_tsc_calibration=1
kern.timecounter.invariant_tsc=1

/etc/sysctl.conf:

kern.timecounter.hardware=TSC-low

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .