Thanks Guillermo. I should have thought about this. So Linux is doing
the right thing (fixing CLOCK_REALTIME on resume), and the problem
only appears with CLOCK_MONOTONIC. It is indeed one of the drawbacks
of using --enable-monotonic when you need a wall clock. And it is a
skalibs problem that
On Sun, Sep 01, 2019 at 10:18:42PM +, Laurent Bercot wrote:
> Yes, it does. But --enable-monotonic is a bad idea for long-lived
> processes that need timestamping. I need better clock interfaces
> in skalibs, the current ones don't allow a run-time selection
> between clocks. Hopefully I can
On Sun, Sep 01, 2019 at 10:54:44PM -0300, Guillermo wrote:
> OK. Going back to Casper's problem, I remember from old posts that he
> is using Void, Void packages a libskarnet built with
> --enable-monotonic, and the man page says that CLOCK_MONOTONIC does
> not count time that the system is
El dom., 1 sept. 2019 a las 19:18, Laurent Bercot escribió:
>
> >Doesn't s6-log (indirectly) use clock_gettime() with a CLOCK_MONOTONIC
> >argument if skalibs was built with --enable-monotonic?
>
> Yes, it does. But --enable-monotonic is a bad idea for long-lived
> processes that need
Doesn't s6-log (indirectly) use clock_gettime() with a CLOCK_MONOTONIC
argument if skalibs was built with --enable-monotonic?
Yes, it does. But --enable-monotonic is a bad idea for long-lived
processes that need timestamping. I need better clock interfaces
in skalibs, the current ones don't
On Sun, Sep 01, 2019 at 08:41:33AM +, Laurent Bercot wrote:
> Short answer: no, the system needs to readjust the system clock when
> resuming from suspension/hibernation; it's a problem not only with
> s6-log, but with every program using the system clock, so the problem
> should be fixed
1. After resuming from suspension or hibernation, s6-log no longer shows
the correct timestamp. Can this be fixed? Thanks.
This is a much more complicated issue than it sounds.
Short answer: no, the system needs to readjust the system clock when
resuming from suspension/hibernation; it's