On Wed, 13 Apr 2011 09:05:23 +0300, "Andrew O. Shadoura" <bugzilla@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
Attachment:
pgpqTxcRRwzyk.pgp
Description: PGP signature