Your message dated Mon, 28 Dec 2020 00:14:00 +0100
with message-id <[email protected]>
and subject line Re: Bug#97349: hwclock doesn't adjust
has caused the Debian Bug report #97349,
regarding util-linux: [hwclock] conflict between clock drift and correction
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.)
--
97349: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97349
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: util-linux
Version: 2.11n-4
Hi,
the handling of the hardware clock is incorrect, because
it mixes two incompatible methods of correcting the
hardware clock, the drift method and the system clock writeback
method. That's bad.
You should have a configuration variable which allows to choose
between the two methods.
If you choose the drift method, the system clock shouldn't be
written back to the clock at shutdown time, this completely
distorts the drift calculation, especially on machines that were
sleeping meanwhile (notebooks).
When drift method is chosen, the clock should never be written back
automatically, but manually only (every few weeks after a ntpdate).
regards
Hadmut
--- End Message ---
--- Begin Message ---
Version: 2.26.2-1
* David Lawyer <[email protected]> [201227 23:09]:
> Package: util-linux
> Version: 2.10q-1
[..]
> 2. Here's the main problem: If one uncomments "hwclock --adjust ..." in
> /etc/init.d/hwclock.sh then your hardware clock may not get adjusted.
> (If you don't uncomment it, it doesn't get adjusted either so you
> can't win.) This is the case for people who turn off their Linux PCs
> more frequently than once a day (or share Linux/Windows on the same
> PC). Here's why it doesn't work:
>
> If an attempt is made to calibrate (to calculate the drift and write it
> into /etc/adjtime) and it's been less than 24 hours since the last
> attempted calibration, then no drift calibration is made (the secs/day
> drift value in /etc/adjtime is not changed).
[..]
>
> This behavior doesn't seem to be documented anywhere.
hwclock 2.26 once again documents this in hwclock(8), including lots
of text on when to use --update-drift and its requirements.
Thanks,
Chris
--- End Message ---
