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 co
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 ([email protected])
> 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
On Fr, 24.08.18 14:52, David Weinehall ([email protected]) 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
> has
Hi,
On 24.08.2018 18:18, Uoti Urpala wrote:
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 w
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 l
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
ma
