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 wrote:
> That
On Sat, Sep 15, 2018 at 3:02 PM D.S. Ljungmark 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,
On Mon, 10 Sep 2018 at 21:13, Lennart Poettering
wrote:
> On Fr, 24.08.18 14:52, David Weinehall (david.weineh...@linux.intel.com)
> wrote:
>
> > We're having two time/date related issues/questions:
> >
> > First of all we'd need some counterpart to ntpdate.
> >
> > We have a system that lacks
On Fr, 24.08.18 14:52, David Weinehall (david.weineh...@linux.intel.com) wrote:
> We're having two time/date related issues/questions:
>
> First of all we'd need some counterpart to ntpdate.
>
> We have a system that lacks an RTC battery--the clock is reasonably reliable
> once the system
>
On Fri, 2018-08-24 at 14:52 +0300, David Weinehall wrote:
> The second time-related issue pertains to journalctl.
>
> It seems that journalctl logs (or at least displays) events in date/clock
> order, not in
> sequence order. While this is definitely useful when trying to correlate
> different
We're having two time/date related issues/questions:
First of all we'd need some counterpart to ntpdate.
We have a system that lacks an RTC battery--the clock is reasonably reliable
once the system
has booted, but every time the device is restarted it loses system time. Due to
the use of the
