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

[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 it only has a compile-time switch.


[ Casper ]

So the supposed changes at [1] will come true?
(As a user, I will surely be glad about the effects.)
[1] 


 I don't think I'll completely overhaul and duplicate the tai.h
functions; in particular, the concept of having one true time source
is very useful and I don't want to part with it if at all possible.
But your report - thank you for it! - is proof that --enable-monotonic
is a bad choice and has to go; and I'll find something with run-time
configurability to replace it.

--
 Laurent

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

[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 write those interfaces for 2.9.0.0.

So the supposed changes at [1] will come true?
(As a user, I will surely be glad about the effects.)
[1] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

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

[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 suspended, so could that be the
> reason of s6-log's incorrect timestamps after suspension or
> hibernation?

Many thanks for the hint, and it is exactly because of this!  I built an
all-static version of s6-log that does not use `CLOCK_MONOTONIC' with
the script in this post, and confirmed that the symptom does not happen
with the customised version:
.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

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

[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 timestamping. I need better clock interfaces
> in skalibs, the current ones don't allow a run-time selection
> between clocks. Hopefully I can write those interfaces for 2.9.0.0.

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 suspended, so could that be the
reason of s6-log's incorrect timestamps after suspension or
hibernation?

* 
https://github.com/void-linux/void-packages/blob/a35ae159d262f867de4b1c12250baae947b6e512/srcpkgs/skalibs/template

On the other hand, as far as I can tell, GNU Coreutil's date(1) just
calls clock_gettime() with a CLOCK_REALTIME argument, so if that works
correctly after suspension or hibernation, in the absence of better
clock interfaces, maybe linking s6-log to a libskarnet build without
--enable-monotonic would work?

G.

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

[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 allow a run-time selection
between clocks. Hopefully I can write those interfaces for 2.9.0.0.

--
Laurent

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

[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 where it occurs.

I roughly see.  Other programs, like date(1) and conky, do seem to
output the correct time after resuming, but I (at least recently, and
you will know why in roughly two to four weeks) really do not have time
to investigate how that is done.

>  This is just a path searching convention, and the proposal is to
> basically add . to PATH for binaries containing (but not starting
> with) a slash. I personally think that anything involving . in PATH
> is a bad idea, but independently from that, I don't see how it relates
> to solving name conflicts in a distribution. Can you elaborate on how
> you would use this?

If I understood it correctly, Goodwin seemed to mean that any invocation
not beginning with `/', `./' or `../' are searched from $PATH, and thus
we can simply use `execline/import' to run `/bin/execline/import'.  BTW,
Plan 9 also has an `import' command: .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

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

[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 a problem not only with
s6-log, but with every program using the system clock, so the problem
should be fixed where it occurs.

Long answer:
- There are several "clocks" accessible to a userland process via
clock_gettime(). They can be roughly classified into "stopwatches"
(they count the incremental time since a given starting point) and
"wall clocks" (they give you the time of day).
- It's often debatable (and debated) what particular clock should
be used for a given program. But in the case of s6-log, the answer
is clearly: a wall clock. Because it's what is used for timestamping.
- POSIX makes no mention of what should happen with clocks when
suspending/resuming the system.
- Linux has *no* wall clock that explicitly counts time spent in
suspension. It only has one (stopwatch) clock that does it, that
is named CLOCK_BOOTTIME.
- CLOCK_BOOTTIME is not usable for s6-log, because 1. it's not
portable, and 2. it's not a wall clock, meaning it can diverge
from the human view of system time over long durations (that's
the reason why wall clocks are generally preferrable to stopwatches
for long-lived processes).
- 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. It is likely done by the next NTP
synchronization after the resume, but there is a window where wall
clocks give inaccurate information. The kernel could probably help
by roughly adjusting CLOCK_REALTIME given the difference between
CLOCK_BOOTTIME and CLOCK_MONOTONIC, but as of now it's not doing it.

More details:
http://man7.org/linux/man-pages/man3/clock_gettime.3.html



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?


 This is just a path searching convention, and the proposal is to
basically add . to PATH for binaries containing (but not starting
with) a slash. I personally think that anything involving . in PATH
is a bad idea, but independently from that, I don't see how it relates
to solving name conflicts in a distribution. Can you elaborate on how
you would use this?

--
 Laurent