Well, systemd itself uses Linux timerfd to receive "clock changed" events. See time_change_fd() in src/basic/time-util.c, and the large comment in clock_state_update() in src/time-wait-sync/time-wait-sync.c in systemd's source tree.
--
On Sat, Sep 15, 2018 at 4:15 PM D.S. Ljungmark <ljungmark@xxxxxxxx> wrote:
That could work, but then it’s still needing a signal to figure it out in order to get it right. Thanks. I’ll see about implementing that.On Sat, 15 Sep 2018 at 14:28, Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:On Sat, Sep 15, 2018 at 3:02 PM D.S. Ljungmark <ljungmark@xxxxxxxx> wrote:I’ve got a follow up here. We want code to run both before and after time is synchronized the first time. But we -also- need to know how big the first time jump is.It’s lokel to be in the matter of weeks or months in our application, and we’d want to know how much it was lagging.We start logging measurements before things are connected, and tag them as unknown, later when we get an application sync on time we can recalculate to proper dates,( provided we weren’t losing power for many times before we get a network sync)AFAIK you could look at the difference between real time and CLOCK_BOOTTIME (or MONOTONIC). Whenever you notice the clock jumping, compare the new difference with the previously seen one, and you'll know how much to offset the old records by. That doesn't depend on any external software and works just as well with timesyncd as it does with ntpdate or manual adjustments.(For example, every journald entry includes the real-time *and* monotonic timestamps.)--Mantas Mikulėnas
Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
