Your message dated Sun, 8 Nov 2020 16:09:32 +0100
with message-id <[email protected]>
and subject line util-linux upstream bugs with no activity
has caused the Debian Bug report #58139,
regarding util-linux: [hwclock] proposed changes to allow other drift
adjustment tools
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
58139: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58139
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: util-linux
Version: 2.10f-2
Severity: wishlist
(Results of the "RFC: proposed changes to hwclock" thread on debian-devel,
2000-02-10 to 2000-02-12. Please forward upstream).
This RFC (Request For Comments) tries to deal with the issue of drift
correction and timekeeping robusteness for "woody", when applied to Debian's
"default" RTC (hardware clock) control utility: "hwclock" from the
util-linux package.
[...]
RTC is used in this RFC to mean the same as "hardware clock" in hwclock's
documentation. Suggested modifications are grouped by the target problem
they're supposed to (help) solve.
NOTE: I am not intimately familiar with the hwclock source, so a few of the
modifications below might be already there, or need tweaking.
Group 1: Other aproaches at RTC sistematic drift computation must be made
possible
Reasoning:
hwclock's default drift computation is severely lacking in various ways,
the most obvious being that it is extremely sensitive to external
tampering with either the system date or the RTC. This is a problem,
because (Debian) users are being hit by this limitation a lot.
Currently, it is completely impossible to use another tool to do the RTC
systematic drift error computation for hwclock's use because hwclock
will overwrite the results.
RTC drift calculation can be done in a much safer way by other
utilities, such as ADJTIMEX, CHRONY and even NTP. hwclock's main
function is to access the RTC, and that's where it excells; we should be
able to use other tools which excell in precise timekeeping to calculate
clock drift.
Modifications to implement:
1. hwclock should be configurable to CHANGE DRIFT and NOT CHANGE DRIFT
(change or not change the RTC drift in /etc/adjtime). NOT CHANGE DRIFT
should effectively turn the RTC drift a read-only value for hwclock.
Do note that /etc/adjtime would still be changed, as the other
variables in there must still be updated.
IMPORTANT: When the RTC drift is in NOT CHANGE DRIFT state, hwclock
must *not* compute a new drift. It must use the drift in /etc/adjtime
if it has to do any drift correction. This is especially true for the
--adjust function.
2. (partially Debian-specific): The default (user has not given any
special options in hwclock's command line) must be made "NOT CHANGE
DRIFT", either by changing the default behaviour for hwclock (requires
agreement of upstream), or by introducing a /etc/hwclock.conf file
where defaults can be kept.
The second option (a defaults file) is the better choice, as it allows
users who still want to use hwclock for drift computation to set the
default to CHANGE DRIFT without recompiling (in Debian).
Group 2: hwclock should be more robust when applying the drift correction.
Reasoning:
The modifications in this group should reduce the number of incidents,
pleas for help in the mailing lists and general annoyance regarding
hwclock and corrupted/ incorrect drift corrections. Those drift errors
are caused by a number of factors, including but not limited to
misbehaving system clocks, human error and interaction with ntp,
ntpdate, date, chrony and other programs.
Improved robustenss is required if the modifications in group 1 is to be
of any practical use for Debian.
Modifications to implement:
1. hwclock should be able to refuse to apply drift corrections which
exceed a given absolute value. Note that "drift correction" means the
total drift as given by |(drift ratio)x(time elapsed since last RTC
update)|.
This absolute limit should be configurable and enabled by default,
using a reasonable default limit (such as 30 minutes).
Setting the absolute drift limit to zero should revert hwclock to the
unlimited drift correction behaviour.
hwclock should issue a warning and not perform write operations which
use the drift correction if the absolute drift limit is violated
(e.g.: --adjust).
2. (optional, but recommended)
If supported and required by the underlying kernel, hwclock must
detect that the kernel is syncronized with an external source and
updating the RTC by itself (the so called "11 minute mode" in Linux)
if any operation which would access (read or write) the RTC is
requested.
Should this condition be detected, hwclock must reset the "drift last
applied to RTC" variable in /etc/adjtime to "unknown" (or to the
current time, if unknown is not supported). It should also set the
drift to zero if in CHANGE DRIFT mode (and issue a warning if in
CHANGE DRIFT mode).
Should this condition be detected in a RTC or system clock write
operation (--adjust, --hctosys, --systohc...), a warning must be
issued and the operation must not be carried out. A command line
option to force the operation to be carried out should be provided.
(For Debian: Debian shutdown scripts should force the RTC update
regardless of the kernel RTC update mode).
3. hwclock should warn the user of possible /etc/adjtime corruption
should the absolute drift ratio stored in the file (or calculated if
in CHANGE DRIFT mode) be larger than a given absolute limit, in a
similar way as explained for the total drift correction in patch 1 of
group 2 above.
Should this condition be detected, the RTC drift should be set to 0 if
hwclock is in CHANGE DRIFT mode, a warning should be issued and the
time of last RTC drift correction set to unknown/now.
Group 3: hwclock's builtin RTC drift computation should be made more robust.
Reasoning:
If it's there, someone will want to use it. This function is not
hwclock's main function and it is severely limited by design, but since
it is there we should at least add a few sanity checks to make it safer.
Modifications to implement:
1. Detect too large variations in the computed RTC drift _when_in_CHANGE_
_DRIFT_mode_ by comparing it to the last calculated drift in the drift
file (/etc/adjtime).
The limit against which the variation of the RTC drift is compared
(ie. how much is 'too large') should be configurable, with a
reasonable default (e.g.: 10s/day). Zero disables this test.
Should this contidion be detected, a warning must be issued, and all
drift correction data must be invalidated.
2. Document common instances of wildly varying clock frequencies:
A common RTC will change its basic frequency with temperature, and
sometimes this variation is rather noticeable. Big variations (as in
some seconds/day) are not uncommon during machine powerup (clock IC
heats up as the motherboard heats up) and nightly powerdowns (clock IC
cools down as the motherboard cools down).
Laptops subject to different ambient temperatures can have frequency
variations of some seconds/day during cold weather, for example.
Users of machines subject to such temperature variances must manually
set the clock to known good time several times per day if they want
any sort of precision, or use something which can deal with
temperature frequency shift (such as ntp) to correct the clock
continously.
-- System Information
Debian Release: 2.2
Architecture: i386
Kernel: Linux godzillah.rivendell.sol 2.2.14 #1 Thu Feb 10 22:30:22 BRST 2000
i586
Versions of packages util-linux depends on:
ii libc6 2.1.3-2 GNU C Library: Shared libraries an
ii libncurses5 5.0-5 Shared libraries for terminal hand
ii slang1 1.3.9-1 The S-Lang programming library - r
-- Configuration Files:
/etc/fdprm [Errno 2] No such file or directory: '/etc/fdprm'
/etc/init.d/hwclock.sh changed [not included]
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--- End Message ---
--- Begin Message ---
Closing wishlist bugs that want to change upstream behaviour, with
no activity for a while.
If you feel your bug is still important enough to keep track of,
please directly contact upstream (again). Preferably with patches.
As a reminder, upstream contact points for bug reports are:
E-MAIL: [email protected]
Web: https://github.com/karelzak/util-linux/issues
Best,
Chris
--- End Message ---
