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 wr
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 suspend
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 timestamping.
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 allo
El dom., 1 sept. 2019 a las 5:41, Laurent Bercot escribió:
>
> - So the only real solution is a mechanism that fixes
> CLOCK_REALTIME (the portable wall clock that is appropriate for
> s6-log) after a resume.
Doesn't s6-log (indirectly) use clock_gettime() with a CLOCK_MONOTONIC
argument if skalib
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 where
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 a
1. After resuming from suspension or hibernation, s6-log no longer shows
the correct timestamp. Can this be fixed? Thanks.
2. Some days ago I stumbled upon [1], and found it possibly a much less
intrusive alternative to a centralised registry for command
names [2]. Any thought on this?