>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
Received on Sun Sep 01 2019 - 08:41:33 UTC