Poul-Henning Kamp wrote on 2005-07-31 06:23 UTC:
> >> I have three times been through what ended up being total reinstalls
> >> from backups because some operator by accident (or stupidity) set
> >> the clock forward in time and then backward in time on a database
> >> installation.
> >
> >Are you asserting that these problems had something - anything at all
> >- to do with leap seconds?
>
> No, they had everything to do with computers don't liking time to
> jump around.
>
> In order to test leapsecond handling, you need to jump the time
> forward to end of june or december, afterwards you need to jump it
> back.
Whenever I test leap seconds in an operating system function, I simply
insert one leap second, and a short time later, I delete another one. In
between, I run test software that shows me the evolution of the 1-second
time offset relative to a comparison system that does not execute the
test leap seconds. If the API you are testing requires you to jump to
the end of June or December, then it simply is a very badly designed API
and should be redone. The API of a kernel clock driver should be able to
schedule the insertion and deletion of a leap second any any start of a
UTC second, usually expressed in POSIX's "Seconds Since the Epoch"
scale. I fail to see, why a leap-second test should require major
disruptions in the monotonicity of your OS clock.
In addition, it is always good practice to keep test and operational
environments strictly separated, for any sort of test, not just those
involving clocks. (With virtalization tools such as Xen or VMware, it
have become very easy to run such tests completely isolated on the same
hardware.)
> Leapseconds is such a stone for real-world IT installations.
Incompetent test design is an orders of magnitude heavier stone ... with
or without leap seconds. I see leap seconds more as one one among
thousands of things that can go wrong with computers, and not one that
has good prospect of ever featuring prominently as a root cause in
software failure statistics.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Mon Aug 01 2005 - 03:58:10 PDT