Re: Scary bugs
On Sat, Jan 29, 2000 at 12:23:02AM +0100, Thierry Laronde wrote:
> On Fri, Jan 28, 2000 at 04:29:37PM +0100, Richard Braakman wrote:
> Package: util-linux (debian/main).
> > Maintainer: Vincent Renardias <vincent@debian.org>
> > 42556 util-linux: hwclock: Continually messes up my clock
> > [WAITING] Maintainer was contacted on Dec 12, awaiting reply.
>
> IMHO, this has nothing to do with an "upstream" bug, nor with alpha either
> (except for the cadence of the processor...).
>
> The reason of this mess is the script /etc/init.d/hwclock.sh, specially
> this part :
>
> stop|restart|reload)
> [ "$GMT" = "-u" ] && GMT="--utc"
> hwclock --systohc $GMT
> ^^^^^^^^^^^^^^^^^^^^^^
I agree. Below is a bug I sent on or around May 7. (I do not know the
bug ID because I didn't save the response. I do know it was in the bug
db for some time.) It is no longer in the bug database because the
maintainer closed it. At the time I did not verify the fix, but if
memory serves, the maintainer said he removed the offending line. It
seems that he did not. Perhaps someone who knows how to dig up old
closed bugs can figure out exactly why it was closed.
I also agree that the easiest fix is to remove the offending line.
Possibly also the similar line in the startup script, but I'm not
positive. A more clever fix might be for hwclock to log its actions
somewhere when run manually to set the clock; then, the shutdown script
could --systohc only if hwclock was not run manually since startup.
However, I have not thought this through so I would not warrant it as a
solution.
(BTW, Alan's quote at the bottom is a propos--it would be cool if
someone would analyze the transitions between status of the hardware
clock, system clock, and adjtime file, and figure out when the --systohc
is safe.)
Andrew
--- forwarded bug report ---
From: pimlott@idiomtech.com
To: submit@bugs.debian.org
Date: Fri, 7 May 1999 16:56:02 -0400 (EDT)
Subject: util-linux: hwclock --systohc dangerous
Package: util-linux
Version: 2.9i-1
Severity: important
I believe that the "hwclock --adjust" in the hwclock startup script and
the "hwclock --systohc" in the shutdown script have considerable
potential for harm, and should be removed from the default installation
of Debian.
First, suppose that I notice that my hardware clock and system clock are
both off by one hour, I use "hwclock --set" to correct the hardware
clock. Since I don't want my system time to change discontinuously, I
do not change my system time. Instead, I reboot cleanly for the new
time to take effect. On shutdown, however, the hardware clock is set
back to the system clock, effectively undoing my action.
Second, suppose that I notice that my hardware clock is wrong, but
instead of changing it with hwclock, I shut down and change it via a
BIOS menu, or DOS. Now, when I boot, "hwclock --adjust" will be
confused about how much time has passed since the last adjustment and
make an incorrect adjustment.
Finally (and this one I'm not so sure about), every time the hardware
clock is set (even with "hwclock --systohc"), hwclock writes drift
information to /etc/adjtime. In the first case above, the clock was
changed twice, both of which might have appeared to hwclock as huge
drifts, which would mess up the clock the next time the system is
restarted and "hwclock --adjust" is run. I believe hwclock does have
some logic to detect large time jumps and not treat them as drifts, but
I know that things can go wrong because they have with my system (my
/etc/adjtime file had a drift of 2796.258301 seconds/day after I
recently played with the clock).
In short, these mechanisms are not reliable unless the user understands
how they work. By putting them in place without the user's knowledge,
you subject him to several pitfalls. Time is too important for this.
Better the clock be inaccurate in a simple and predictable way.
If you have thought this through and don't consider it a problem, please
share the reasons.
Thanks,
Andrew
--
A computer is a state machine. Threads are for people who can't program
state machines.
- Alan Cox
Reply to: