![]() The man page for adjtimex provides a couple of interesting portions that pertain to what you are asking: The buf.status field is a bit mask that is used to set and/or retrieve status bits associated with the NTP implementation. Hence it gives you the ability to peek into the kernels idea of what sync is being done (if any). The adjtimex system call is typically used by NTP systems to change the current skew the clock is facing to get it to synchronize correctly with a true clock source - but it can also be used to fetch the current status of the skew of the clock source. The kernel doesn't want to have time jumps in its reporting of the time (or worse, time travelling backwards) as such it implements a skew in the time which over a the course of a few hours would correct a systems time (its done by adding or delaying a few milliseconds per second until the adjustment is complete). Hence, the second way to do this yourself without a full implementation is by using the adjtimex() system call. What it is doing is perfoming a system call: adjtimex from which its possible to get data back indicating the current status of the adjustment in the kernel (if any) that is being done. The way that this is internally managed is via dbus which speaks to the systemd-timedated daemon. If the container you're running has a full systemd implementation, then the timedatectl program can inform you if the host is synchronized or not. Cannot check for a proper ntpd running, but can sanity check offsets regardless of how time sync works to the host. Perhaps bundling a SNTP client, which checks NTP offsets in your application, against configurable NTP servers. This aggressive of a response implies the application does its own time checks. ![]() Most demanding I can think of is time stamping authorities, one of which claims standards require less than one second offset or nothing can be issued. Yet there are applications with strict time requirements. On RHEL, to wait for time sync systemctl enable chrony-wait and add to your systemd unit After=time-sync.target ![]() On some platforms, making a dependency on an ntpd starting is relatively straight forward. Often documentation of the importance of correct time is sufficient. Further making a general answer difficult, there are more NTP implementations than you might think: chrony, ntp, ntpsec, openntpd, w32tm. Or a VM guest that relies on host time sync, also not visible. In a container, you do not see and cannot connect to the chronyd or ntpd running on the host, yet this keeps time just fine. Applications on general purpose compute cannot know in all cases how time sync works on the hosts they run on. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |