Prev: Final report was Re: Problems with udev
Next: autofs: mounting a windows SMB share on centos
From: cc-tec on 17 Jan 2008 05:01
hi group, hi all,

thks for all hints,

for my 'initial' problem

hwclock changing system time by 22 or 23 seconds on --systohc and
reverse --hctosys calls when the system is configured acc. djb's
(Daniel? J. Bernstein's) configuration for 'clockspeed' internally
dealing with tai or something like that - look into the thread
'hwclock problem with leapseconds - posix?'

it looks that replacing all timezone files used by the system (/usr/
share/zoneinfo) with those from the 'olson' or 'right' directory (you
can mostly undo that by replacing them with those from the 'posix'
subdirectory) is much better then just linking /etc/localtime to the
timezone file in the 'right' subdirectory because:

- either the system needs more than one timezone file for doing
internal calculations (at least the utc one when referring to utc
times),

- or ??? have to recheck ??? the access to the localtime file doesn't
work on boot when just linked instead copied, i had some strange
messages about access to xxxxxx in my F10 console when /etc/localtime
was just a link, ??? have to recheck ???,

just be aware that these changes do! affect routines burried deep in
your system and it's a part of the system that's not! clean,

on my systems it's left that date -u is less than one hour different
from cet,

and cron jobs start at xx.yy.38 rather than at ....00 as they used
before the changes,

read the below comment from Unruh,

who wants to learn more about the problem may read here

http://www.hko.gov.hk/wservice/tsheet/timeserv.htm

a nice and short info about the need and introducion of a reliable
time,

and here

http://www.cis.udel.edu/~mills/database/papers/leapsecond.pdf

some deep and concrete info showing that also prof mills (the pope for
ntp?) thinks that tai is somewhat preferable to utc, and that the
problem is quite some years old, and so on,

i think it's time to start with changes, finding a concrete and
homogen definition for time and localtime and implement them into our
systems, otherwise - in the standard way 'it' in this world evolves -
we'll have to talk about these points on and on and on ....

but my initial problem is solved, thus this message here,

thks to all,

helpless user

Unruh wrote:

....

> Thus, the key would seem to be to replace the the files in
> /usr/share/zoneinfo with the files in /usr/share/zoneinfo/right, Part of
> the problem as well is that in various places in Linux, programs "roll
> their own" calculation of UTC from seconds since epoch. Thus for example,
> the rtc code in the kernel demands that the ioctl be fed with broken down
> time ( seconds since epoch) but actually stores the time in some weird
> seconds since unknown epoch form, instead of feeding it with seconds since
> Linux epoch. Ie, to properly have your system running on TAI time, there is
> a lot of stuff in Linux you have to change. While I agree that leapseconds
> are silly the way they are implimented (they are an approximation to solar
> seconds-- ie having exactly 86400 seconds from mean noon to mean noon each
> day-- which means that the lengthof the second compared to atomic time
> changes each day) having Linux actually use TAI or modified TAI properly is
> a highly non-trivial undertaking.
>
> Note that "fix" for example to hwclock by having yet another UTC calculation
> done on the fly, makes matters worse not better. There should be one single
> routine that does it. And the rtc clock should deliver its time in seconds
> since epoch, as it is stored, rather than in a broken down time, but fixing
> it all would be a huge enterprise. Thus, leaving things on UTC and putting
> up once a year or so with leapseconds certainly seems the more intelligent
> procedure, until someone completely rewrites all of the timekeeping stuff
> in Linux, ntp, ...
>
> (PS, did others also get this repeat of this message-- I first saw it two
> days ago, and now see it again-- or is it my mail reader/nntp host)

....
From: Bill Marcum on 17 Jan 2008 09:06
On 2008-01-17, cc-tec(a)gmx.de <cc-tec(a)gmx.de> wrote:
>
> - or ??? have to recheck ??? the access to the localtime file doesn't
> work on boot when just linked instead copied, i had some strange
> messages about access to xxxxxx in my F10 console when /etc/localtime
> was just a link, ??? have to recheck ???,
>
Maybe the boot scripts try to read /etc/localtime before /usr is
mounted? Can't think of any other reason a link would work differently.

From: cc-tec on 21 Jan 2008 14:46
hi,

Bill Marcum wrote:

> Maybe the boot scripts try to read /etc/localtime before /usr is
> mounted? Can't think of any other reason a link would work differently.thks for the idea

thks for the hint, but nope, /usr is fully contained in /, not on an
extra partition,

so there must be something else, will post about it when i find time
to check,

thks,

helpless user
 | 
Pages: 1
Prev: Final report was Re: Problems with udev
Next: autofs: mounting a windows SMB share on centos