Ntp time (chrony) not synchronized

CMK version: 2.0.0p12 (CRE)
OS version: centos 7

Error message:

i have an instance running chrony as a Network Time Protocol and it’s synchronized inside the machine but not in the check_mk UI as you can see in the above image.

Please any idea what could be the problem?

Hi @ElZakariyae, welcome to the forum!

According to your screenshot, your WARN/CRIT threshold for “Time since last sync” is two (2) hours, resp. (4) hours. The check result reports, that your last sync was eight (8) days and eight (8) hours ago. The CRIT condition is fulfilled, so you get an alert.

If you want to change this behaviour, you need to modify the corresponding rule. In my Checkmk 2.0.0p21 instance, the rule is called “State of NTP time synchronization”.


1 Like

Here is also a thread to the chrony last sync problem describing what really happens.

1 Like


Thanks for your answer, that’s exactly the problem i have, the NTP service synchronization is working fine on all the machines with the same WARN/CRIT threshold expect 2 or 3 machines that i should synchronize them manually by running the check_mk_agent command after that they go critical when the condition is fulfilled until i run the check_mk_agent command again (manually).

note that the output of chronyc tracking looks okay:

chronyc tracking
Reference ID : B978160C (ntp01.fra-pool.fastether.net)
Stratum : 3
Ref time (UTC) : Tue Mar 22 21:34:33 2022
System time : 0.000037320 seconds fast of NTP time
Last offset : -0.000014906 seconds
RMS offset : 0.000113510 seconds
Frequency : 32.930 ppm slow
Residual freq : -0.000 ppm
Skew : 0.065 ppm
Root delay : 0.014482673 seconds
Root dispersion : 0.001599295 seconds
Update interval : 260.8 seconds
Leap status : Normal


Thanks, i adapted my config following the solutions described in that post but with no luck, i’m still getting ntp critical in some of my monitored machines as described in the previous reply.

Hi @ElZakariyae

So when you execute the command manually (chronyc tracking) you get
correct data, but with the Checkmk check, you don’t?

It could be, that the chrony cache file isn’t properly updated, but when
you execute the agent manually a few times - as you say - you get the
expected result.

How exactly are you contacting the “problematic” hosts, meaning: Is their agent output, provided via systemd or xinetd (officially recommended)? Does it make a difference whether you use one method
or the other?

Another idea: As per your initial post, you are on 2.0.0p12. Perhaps you could attempt to update to the latest 2.0.0 version (most recent release is p22: as far as I understand, it might be a “short lived” version) including the agent, and see if this behaviour is mitigated.


Hi @ElZakariyae

I have resolved this problem in conjuction with my linux engineer by removing chrony from problematic servers and replacing with ntp.

Hope it helps.

Best regards,

Can someone give me some breadcrumbs for fixing this in a way that doesn’t remove chrony? I can’t seem to locate the rule that causes this to fire off for modification, not can I eve say for sure what’s being measured to decide that there is a problem to notify about (perhaps the ‘update interval’? as reported by chronyc tracking?). non of my machines ever seem to get even a second out of sync from ntp time, so getting this error thrown at random times is frustrating at best and not useful by any measure that I can come up with.



Thank you all for your help, just in case someone has the same issue, the following solution solved mine:

ssh to the server and clear cache.

rm /var/lib/check_mk_agent/cache/chrony.cache

And generate cache again by run check_mk_agent


Update: Clear cache only fix it temporarily. Need start check_mk-async.service to fix it permanently.

systemctl enable check_mk-async.service
systemctl start check_mk-async.service
systemctl status check_mk-async.service