FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-13-2011, 06:05 AM
"Andrew O. Shadoura"
 
Default rock around hwclock.sh

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?

iii) Also, it would be good to hear opinions about negative
consequences of saving the system time to the RTC on frequent basis.

Thanks for your responses.

--
WBR, Andrew
 
Old 04-13-2011, 06:32 AM
Timo Juhani Lindfors
 
Default rock around hwclock.sh

"Andrew O. Shadoura" <bugzilla@tut.by> writes:
> iii) Also, it would be good to hear opinions about negative
> consequences of saving the system time to the RTC on frequent basis.

My openmoko does a suspend/resume cycle every 10 minutes. RTC time can
only be set at one second granularity. If I write to RTC on every
suspend cycle inaccuracy starts to accumulate.

My solution: Never write to RTC. I let the RTC drift as freely as it
wants and always just set the system time based on RTC. I have
calculated how much the RTC drifts so it is not a problem that the RTC
is actually already an hour off-the-UTC :-)

Some benchmarks:

http://lists.openmoko.org/pipermail/openmoko-kernel/2009-May/010161.html

Patch to make hwclock easier to use when RTC is wildly off-the-UTC
(upstreamed a year ago):

http://www.spinics.net/lists/util-linux-ng/msg03026.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 84ipuiy82s.fsf@sauna.l.org">http://lists.debian.org/84ipuiy82s.fsf@sauna.l.org
 
Old 04-13-2011, 07:51 AM
Philip Hands
 
Default rock around hwclock.sh

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
%y
%z
' /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
 
Old 04-13-2011, 09:55 AM
Adrian von Bidder
 
Default rock around hwclock.sh

On Wednesday 13 April 2011 08.05:23 Andrew O. Shadoura wrote:
> 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?

run hwclock stop only at shutdown, but set system clock to latest(rtc,
hwclock stored time + delta, /var/log/syslog + delta) at boot?

I am aware that not everybody has /var/log/syslog in heavily customized
installs, but if it's there, it's usually occasionally written to. And using
that is certainly faster than "find most recently modified file on all
filesystems" :-)

-- vbi

--
featured product: ClamAV Antivirus - http://www.clamav.net/
 

Thread Tools




All times are GMT. The time now is 01:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org