Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Laurent Bercot
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

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Casper Ti. Vector
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

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Casper Ti. Vector
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

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Guillermo
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

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Laurent Bercot
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

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Casper Ti. Vector
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

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

2019-09-01 Thread Laurent Bercot
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