Why the time of my Appliances is not synchronized?

Question:

The time of my is not synchronized within my Infrastructure.

How can I fix it?

Answer:

There can be some reasons why the time of the Appliances is not being synchronized with your organization's time.

NTP servers are not configured

Network Time Protocol (NTP) servers are commonly used among organizations to assure all their servers and client machines will use the same time, mainly to avoid having inconsistencies in their communications.

To configure it, you can check the FAQ article we have created for that (refers to our documentation):

How can I make sure my Nexthink Appliances are time-synchronized in my network?

NTP servers configured are not valid/reachable

It can happen that for some reason the NTP servers are not reachable or not valid anymore.

To know if this is the case, you can check if the NTP servers are reachable via UDP 123 port, and your Infrastructure allows this communication. This is specially important to be checked if you don't use third-party NTP servers but your own ones.

More information about the Connectivity Requirements for NTP servers can be found in our documentation: Connectivity Requirements

NTP server time and Appliance time are not close enough

NTP is designed to work when the client and the NTP server time is fairly close. NTP will not work if the time difference between server and client is higher than 1000 seconds (default sanity).

A typical example of this can be found here in /var/log/messages.

Feb  4 04:05:32 nxengine ntpd[9191]: 0.0.0.0 c617 07 panic_stop +19908 s; set clock manually within 1000 s.
Feb  4 04:05:32 nxengine systemd: ntpd.service: main process exited, code=exited, status=255/n/a
Feb  4 04:05:32 nxengine systemd: Unit ntpd.service entered failed state.
Feb  4 04:05:32 nxengine systemd: ntpd.service failed.

If that's the case, you will have to manually configure the date and time.

After manually setting a date and time that is closer to the one that the NTP server has, proceed with the re-configuration of the NTP server(s).

The virtual machine picks up the time and date from the hypervisor

Another source of these problems can occur if the virtual machine is configured to pick up the time and date from the hypervisor.

The screenshot is from the WMware workstation but ESX and other products should have a similar option to disable this behavior.

To check the NTP status, run this command:

ntpq -p

In order to manually set the date, use the following command:

ntpdate

We have also found this useful information in the NTP manual:

Most operating systems and hardware of today incorporate a time-of-year (TOY) chip to maintain the time during periods when the power is off. When the machine is booted, the chip is used to initialize the operating system time. After the machine has synchronized to a NTP server, the operating system corrects the chip from time to time. In case there is no TOY chip or for some reason its time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand. This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the clock will be set to the server time regardless of the chip time. However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway.