On Wed, 13 Apr 2011 09:05:23 +0300, Andrew O. Shadoura bugzi...@tut.by
wrote:
Hello,
I'd like to hear opinions on hwclock.sh operation.
Few thoughts of my own:
i) It's still quite common that battery in the RTC becomes flat.
In this case, hwclock.sh silently sets system clock to 1970 (or
whatever else nonsense), efficiently turning file access and modify
times into a mess, and also causing at least two fscks of the root fs.
It'd be good if `hwclock.sh stop` stored the current system time in a
file, and on boot, if the current time (as per RTC) is earlier,
set the system clock to $storedtime + small-enough-constant, so at
least the time runs forward. I've implemented this on my local machine
(I had problems with my RTC for a while) and it worked. And yet more:
NTP isn't always available, especially whe you're mobile.
ii) Possibly, `hwclock.sh stop` should be run more frequently than just
once on shutdown, because it sometimes happens that the system doesn't
shut down correctly. If that happens after some time correction (like
DST), system time can go wrong, and ntp might not perform the automatic
correction. Possibly, hwclock saving can be done, for example, once a
day per anacron, or... any more ideas?
One possibility here would be to look for files that are being routinely
touched anyway (i.e. /var/log/syslog) and taking the most recent of
those as the time to start with. We could also look at atimes (although
people often mount things we might want to look out for with noatime).
Of course, there are problems with this -- /var is probably not mounted
when hwclock.sh is run and the local admin might have decided to send all
logging via the net, so no files are being touched.
Also we're currently trying to ensure that it's possible to run with a
read-only / (the last of which is likely to cause problems for anything
that needs to touch a file that's available early enough for this to
work). This is never going to work on systems that are read-only except
for the ramdisks they mount.
I suppose we could make the script look for evidence that something
funny is going on (i.e. if RTC is set to a date before the release date
of the util-linux package, we then hunt for more likely indicators)
We could also re-run hwclock.sh (or a new script) later in the boot if
it was found that the date was bogus in the first place -- we could then
look at the dates on log files, etc. (with all the same caveats)
iii) Also, it would be good to hear opinions about negative
consequences of saving the system time to the RTC on frequent basis.
If you do the simple-minded thing of assuming that the file with the
date in it is correct, then I see a danger that the clock could somehow
get set momentarily into the far future, and then saved, and that every
reboot would then confusingly jump back into the future because that
date still exists in the saved-date file -- hence, I think that it would
be fair enough to have an initial check to see if the system date is
before the date that the util-linux package was built, say, and only
enable this extra code if we're sure that there's a problem -- it cannot
then make things much worse even if it is based on some pretty fragile
assumptions about where we might find a better guess for the date.
Cheers, Phil.
P.S. something like this may be helpful somewhere in your scripting:
stat --printf='%x\n%y\n%z\n' /var/l??/* /boot/* /etc/* | sort | tail -1
--
|)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-| HANDS.COM Ltd.http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
pgpU1tUHFnRbb.pgp
Description: PGP signature
