The simplest way to sync time using ntp.

[drp]

I've found tutorials and documentation on this, and have read about it before (when using Linux)... but if you know, what is the easiest way to install and use ntp for keeping the time in sync? I'm just wondering what the very simplest way is.

 

[drp]

The easiest way I've ever seen to do it is using the clock of whichever desktop environment you're using, when it has the option of using NTP. Whether or not it clashes with other NTP setups or whatever else, I have no idea. I'm a little confused about the different options there are, and whether or not they conflict with each other, etc.

 

[gordon@]

In FreeBSD, I recommend you use both ntpdate and ntpd. ntpdate will set the clock when you first boot so it's close enough that ntpd will work with it.

You can just add the following to /etc/rc.conf:

ntpd_enable="YES"
ntpdate_enable="YES"

Then read through /etc/ntp.conf. It's pretty well documented so it should be pretty obvious what to set.

 

[gilinko]

Or install openntpd from ports, which is much simpler and in my opinion works a lot better then the native ntpd daemon. No need to worry about stratum or anything else like that, just point it at a ntp server and let it go. However do use ntpdate to set the time and date on boot, to always have a good clock to start with.

 

[rbelk]

In FreeBSD, I recommend you use both ntpdate and ntpd. ntpdate will set the clock when you first boot so it's close enough that ntpd will work with it.

You can just add the following to /etc/rc.conf:

ntpd_enable="YES"
ntpdate_enable="YES"

Then read through /etc/ntp.conf. It's pretty well documented so it should be pretty obvious what to set.

Gordon, I've only use ntpd only at startup. I guess it doesn't make a difference though.

#----------ntp config
ntpd_enable="YES"
ntpd_sync_on_start="YES"

 

[drp]

ntpd_enable="YES"
ntpd_sync_on_start="YES"

Thanks, rbelk, that works for me. When I tried it the other way, it was giving me errors saying "hostname nor servname provided" and "cannot find host" or "cannot resolve host" or something along those lines. Now it's working fine.

 

[drp]

That's just what I was looking for, that's the simplest thing I can think of doing.

 

[gordon@]

Ah, looks like ntpd_sync_on_start does the same thing that ntpdate does for you. Good to know (to avoid having to fork an additional process during bootup).

 

[phoenix]

Or install openntpd from ports, which is much simpler and in my opinion works a lot better then the native ntpd daemon. No need to worry about stratum or anything else like that, just point it at a ntp server and let it go. However do use ntpdate to set the time and date on boot, to always have a good clock to start with.

openntpd_flags="-s" will tell openntpd to sync the clock when it starts (jumping the clock by X seconds if needed), then keep the clock in sync afterward.

 

[chrislongros]

There are plenty of times that I run a VM with FreeBSD and when I suspend my Laptop the date and time are not more updated. ntp can not synchronize due to high offset. Which command can I use without rebooting the VM?

Sorry I now noticed that the posts above are from 2010...

 

[gpw928]

Add tinker panic 0 to /etc/ntp.conf. It allows ntpd(8) to make huge corrections when required, typically after waking from sleep or a vMotion.

 

[chrislongros]

Tried it, still required ntpd service restart

 

[Erichans]

Add tinker panic 0 to /etc/ntp.conf.

Tried it, still required ntpd service restart

ntp.conf(5):

[...]
       tinker  [allan  allan  |	 dispersion  dispersion	| freq freq | huffpuff
	       huffpuff	| panic	panic  |  step	step  |	 stepback  stepback  |
	       stepfwd stepfwd | stepout stepout]
	       This  command  can be used to alter several system variables in
	       very exceptional	circumstances.	It should occur	in the config-
	       uration file before any other configuration options.

Did you put the tinker directive at the top of the configuration file?

I also suggest you observe and wait for 3 minutes after the VM is wakened to see the tinker directive to "kick in", IIRC setting tinker panic 0 does not work immediately after a wake up of the VM.

 

[gpw928]

As Erichans suggests, it takes a little while. Edit: I just measured the delay at 6 minutes on my notebook VM.

You can watch what's happening with ntpq -pn.

Also, just to cover all the bases, make sure you restart ntpd after changing the config file.

 

[gpw928]

If the ntpd delay to sync the clock is an issue, you could try using net/chrony instead.

I have never used it, but do suspect that it might handle wake-ups faster. Others may be able to confirm.

 

[SirDice]

/etc/rc.resume actually restarts /etc/rc.d/ntpd. But that might not be the case for OpenNTPd or Chrony rc.d(8) scripts.

rc.resume:

files=`rcorder ${rcorder_opts} /etc/rc.d/* ${local_rc} 2>/dev/null`

for _rc_elem in $files; do
        debug "run_rc_script $_rc_elem resume"
        run_rc_script $_rc_elem resume
done

That 'resume' is defined in /etc/rc.d/ntpd:

ntpd_resume()
{
        run_rc_command restart
}

 

[Erichans]

Tried it, still required ntpd service restart

/etc/rc.resume actually restarts /etc/rc.d/ntpd.

If the last quote means that when a VM is awakened/started ntpd goes through a restart (=stop followed by a start) just as during a normal boot, then the desired effect of quickly synchronising by use of ntpd should be attainable with a combination of the use of iburst* and ntpd_sync_on_start. These commands are perhaps likely to synch even quicker than with the tinker panic 0 directive and IMO preferable to the tinker directive as this directive also stays in effect after the initial synching.

ntpd(5):

USAGE
How NTP Operates
[...]
       Finally,	 in  the  past	many  startup  scripts would run ntpdate(8) or
       sntp(8) to get the  system  clock  close	 to  correct  before  starting
       ntpd(8),	 but this was never more than a	mediocre hack and is no	longer
       needed.	If you are following the instructions in "Starting  NTP	 (Best
       Current	Practice)"  and	 you  still need to set	the system time	before
       starting	ntpd, please open a bug	report and document what is going  on,
       and  then look at using sntp(8) if you really need to set the clock be-
       fore starting ntpd.

       There is	a way to start ntpd(8) that often addresses all	of  the	 prob-
       lems mentioned above.
Starting NTP	(Best Current Practice)
       First, use the iburst option on your server entries.

       If  you	can  also  keep	a good ntp.drift file then ntpd(8) will	effec-
       tively "warm-start" and your system's clock will	be stable in under  11
       seconds'	time.

       As  soon	 as  possible  in  the startup sequence, start ntpd(8) with at
       least the -g and	perhaps	the -N options.	 Then, start the rest of  your
       "normal"	processes.  This will give ntpd(8) as much time	as possible to
       get the system's	clock synchronized and stable.

ntp.conf(5)

Configuration Commands
   [...]
       iburst  When  the  server is unreachable, send a	burst of eight packets
	       instead of the usual one.  The packet spacing is	normally 2  s;
	       however,	 the  spacing  between	the  first  two	packets	can be
	       changed with the	calldelay command to allow additional time for
	       a modem or ISDN call to complete.  This is  designed  to	 speed
	       the initial synchronization acquisition with the	server command
	       and s addresses and when	ntpd(8)	is started with	the -q option.

rc.conf(5)

       ntpd_sync_on_start
		   (bool)  If  set  to "YES", ntpd(8) is run with the -g flag,
		   which syncs the system's clock on startup.  See ntpd(8) for
		   more	information regarding the -g option.  This is  a  pre-
		   ferred  alternative	to  using ntpdate(8) or	specifying the
		   ntpdate_enable variable.

For a location in the Netherlands, I have for /etc/ntp.conf

pool 0.nl.pool.ntp.org iburst
pool 1.nl.pool.ntp.org iburst
pool 2.nl.pool.ntp.org iburst
pool 3.nl.pool.ntp.org iburst

For /etc/rc.conf:

ntpd_enable="YES"
ntpd_sync_on_start="YES" #sync time at startup in a big leap; after that gentle clock synchronization
ntpd_oomprotect="YES" # protect ntpd from being killed by the system attempting to recover from an Out Of Memory (OOM) condition.

If you judge timekeeping rather essential then you may consider adding ntpd_oomprotect to protect ntpd from falling prey to OOM.

___
* do not use burst, How do I use pool.ntp.org?:

Be friendly. Many servers are provided by volunteers, and almost all time servers are really file or mail or webservers which just happen to also run ntp. So don't use more than four time servers in your configuration, and don't play tricks with burst or minpoll - all you will gain is extra load on the volunteer time servers.

 

[gpw928]

I think that we need to distinguish between different types of suspension, i.e. a laptop running FreeBSD native and a FreeBSD VM running under some hypervisor.

For the VM, maybe you need emulators/qemu-guest-agent (which appears to be defunct) installed? We tread where others have been.

 

[gpw928]

I did some testing on my FreeBSD VM running under KVM.

Installing emulators/qemu_guest_agent and and setting qemu_guest_agent_enable="YES" in /etc/rc.conf didn't help. i.e. ntpd was not restarted after closing the lid for 5 minutes, and opening it again.

I switched from ntpd to chrony (default configuration), and that didn't help either. There's a specific option to set the VM clients virtual clock from the hypervisor clock ("rtcsync"), but that's only available to Linux clients.

I'd be disappointed if there's not a better way to properly wake a sleeping VM's ntp dæmon than waiting 6 to 10 minutes for ntpd's "tinker panic 0" to kick in.

 

[gpw928]

[Edit: the changes described below work when the KVM FreeBSD client is paused using the KVM virt-manager GUI, but not when I close, and some time later, open the lid of my notebook (which is also a KVM server with a FreeBSD client). Investigations continue...]

After a little effort I have worked out how to correct the system time on a FreeBSD KVM client when it wakes up after being suspended.

You can't just install the qemu_guest_agent package and expect it to work. I had to do some digging...

The github repository for the qemu_guest_agent is relevant, as is documentation on enabling the guest agent for the VM client on the KVM server.

# On the FreeBSD client, install and configure the guest agent
pkg install qemu_guest_agent
# Add the following to /boot/loader.conf
virtio_console_load="YES"
# Add the following to /etc/rc.conf
qemu_guest_agent_enable="YES"
qemu_guest_agent_flags="-d -v -l /var/log/qemu-ga.log -p /dev/ttyV0.2"
# Shutdown the FreeBSD KVM client
sudo shutdown -p now

# On the KVM server, enable communication with the guest agent.
# A side effect is that this will cause the creation of /dev/ttyV0.2 on the client.
host=gunsynd    # name of the FreeBSD client
sudo EDITOR=vi virsh edit $host # Add the following after the first "</channel>" you find
<channel type='unix'>
   <target type='virtio' name='org.qemu.guest_agent.0'/>
</channel>

Boot the client, and verify that the guest agent is running and that the required special files are in place:

[gunsynd.139] $ sudo  service qemu-guest-agent status
qemu_guest_agent is running as pid 699.
[gunsynd.140] $ ls -la /dev/vtcon/
total 1
dr-xr-xr-x   2 root  wheel  512 Nov  6 12:30 .
dr-xr-xr-x  10 root  wheel  512 Nov  6 12:28 ..
lrwxr-xr-x   1 root  wheel   10 Nov  6 12:30 com.redhat.spice.0 -> ../ttyV0.1
lrwxr-xr-x   1 root  wheel   10 Nov  6 12:30 org.qemu.guest_agent.0 -> ../ttyV0.2
[gunsynd.141] $ ls -lad /dev/ttyV*
crw-------  1 root  wheel  0x38 Nov  6 12:30 /dev/ttyV0.1
crw-------  1 root  wheel  0x39 Nov  6 13:05 /dev/ttyV0.2

Test the KVM server can control the VM client:

[farlap.1365] $ host=gunsynd
[farlap.1366] $ sudo virsh qemu-agent-command $host  '{"execute":"guest-get-osinfo"}'
{"return":{"name":"FreeBSD","kernel-release":"13.3-RELEASE-p7","version":"13.3-RELEASE-p8","pretty-name":"FreeBSD 13.3-RELEASE-p8","version-id":"13.3","kernel-version":"FreeBSD 13.3-RELEASE-p7 GENERIC","machine":"amd64","id":"freebsd"}}

And after suspending and resuming the FreeBSD client (gunsynd) I had this:

[gunsynd.130] $ sudo cat /var/log/qemu-ga.log
1730856559.605833: debug: read data, count: 59, data: {"execute":"guest-sync", "arguments":{"id":1730856686717}}
1730856559.605941: debug: process_event: called
1730856559.605952: debug: processing command
1730856559.605981: debug: sending data, count: 26
1730856559.608536: debug: read data, count: 70, data: {"execute":"guest-set-time","arguments":{"time":1730856686717444419}}
1730856559.608590: debug: process_event: called
1730856559.608597: debug: processing command
1730856686.717506: debug: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead
1730856686.718338: debug: sending data, count: 112

and the system time on the FreeBSD client was correct.

 

[gpw928]

My traveling notebook runs Linux and KVM native. This part is Linux Laptop specific. I'm posting it here because it supports FreeBSD clients.

I already have the clients adjusting their clock when I use the virt-manager to suspend and resume by the method shown directly above.

This is how I get the KVM clients to adjust their time when the lid is shut (acpi suspend) and then opened (acpi resume). The qemu_guest_agent must be installed on the KVM client, as shown in the post above. This code installed on the KVM server:

sudo apt install acpid
sudo cat - >>/etc/acpi/events/lm_lid <<'EOF'
event=button/lid.*
action=/etc/acpi/lid.sh
EOF
sudo cat - >>/etc/acpi/lid.sh <<'EOF'
#!/bin/sh

# https://linuxconfig.org/how-to-handle-acpi-events-on-linux
# https://askubuntu.com/questions/517683/laptop-doesnt-hibernate-when-i-close-the-lid-in-ubuntu-14-04/518825#518825

# NOTE: runs as root
export PATH=/bin
LOGTAG='LaptopLid'
LOGPRI='local0.notice'

if grep -q open /proc/acpi/button/lid/LID0/state >/dev/null 2>&1
then
    logger -p "$LOGPRI" -t "$LOGTAG" "lid opened"
    VMclients=$(virsh list | grep running | awk '{print $2}')
    for host in $VMclients
    do
      virsh qemu-agent-command $host "{\"execute\":\"guest-set-time\",\"arguments\":{\"time\":$(date +%s%N)}}"
    done
fi
sudo chmod a+x /etc/acpi/lid.sh
EOF