Re: Following log directories

From: John W Higgins <wishdev_at_gmail.com>
Date: Fri, 26 Jun 2020 12:52:39 -0700

On Fri, Jun 26, 2020 at 2:27 AM Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:

>
>
> Please bear in mind that this only impacts the time *display*, i.e.
> when you want to print the current time to users, typically in a
> broken-down fashion. The whole point of using TAI in the first place
> is that time computations are kept simple and exact, and do not need
> leap second awareness or clock torture techniques such as leap smear
> (only Google is evil enough to have invented that). TAI is still the
> correct way to represent time internally, and difficulties such as
> "need to look at a leap second table" only arise when you want to
> convert it to something that humans traditionally use, such as UTC or
> local time, in order to display it in a form that is suitable for
> human consumption.
>
>
> >It looks like lnav took the concept from daemontools and ran with it - far
> >worse decisions have been made by a tool trying to accomodate users.
>
> It is definitely not a critical bug, but it is a bug nonetheless, that
> shows a lack of understanding of the historical context, the use cases
> of TAI and UTC, and the relationship between the two. It would be worth
> reporting it to lnav, so it can print accurate information.
>
>
Except it's not quite that simple either.

As an example

echo "s6" | s6-log -t /tmp/a && echo "djb" | multilog t /tmp/a && echo "s6"
| s6-log -t /tmp/a

Produces the following /tmp/a/current file on my system, roughly as a write
this.

_at_400000005ef64dd2075013a2 s6
_at_400000005ef64db707675514 djb
_at_400000005ef64dd2077fa679 s6

There is a large problem there for someone building a tool to show
timestamps that begin as TAI. Either the middle one is 27 seconds in the
past or the first and last are 27 seconds in the future.

If one wants to support djb tooling - then leap seconds are off the table -
if one wishes to support s6 - leap seconds come on the table. What nosh
supports is unknown to me.

When lnav implemented the support - they did exactly what sounds reasonable
- they took the tool they wished to support (multilog I would presume as it
mentionds cr.yp.to) and implemented the code required to produce a view of
that tool's logs. To say that is a lack of understanding is rather harsh
here.

John

P.S. I totally appreciate s6 and all its beauty - I really just wanted to
point out to the original poster that they need to double check because the
worst thing one can do is miss something like this and then wonder why
their logs are off when they go and look at a production system. 27 seconds
seems obvious to catch - but in development one doesn't always focus enough
- it's not like 2 hours or something more obvious.
Received on Fri Jun 26 2020 - 19:52:39 UTC