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 <[email protected]> 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 <[email protected]> wrote: > >> On Sat, Sep 15, 2018 at 3:02 PM D.S. Ljungmark <[email protected]> >> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
