Bind on NON Y2K Compliant System

[C. R. Oldham]

Mark Olbert wrote:

> I'm running bind (v8+) on a linux system which I believe is not Y2K
> compliant (meaning that the hardware is not Y2K compliant). I say this
> because whenever I try to set the hardware clock to a date in January,
> 2000, the date shows up (upon reboot) as being in January, 2094.

Linux only uses the CMOS clock to set the date/ time at boot.  From then
on out it uses the kernel clock. What about booting single user and
setting the Unix date correctly, then continuing the boot into multiuser
mode?  I suspect you might be looking at two different problems--your CMOS
clock, and the fact that expressing 2094 as a 32-bit unix time_t will
overflow.  Depending on your architecture and libc version your Linux may
still have 32-bit time_t.

So the scenario might be:

Kernel starts, reads current time from CMOS
Kernel finds 2094 date, tries to stuff it in a 32-bit time_t
time_t variable overflows, setting the date back several centuries (I
think)
Named starts and thinks all cache entries are way in the past

What does 'date' say after you boot?

Depending on your distribution there might be a way to prevent your kernel
from reading the time from the CMOS clock and instead use something like
xntp to set the time from a reliable network source.

--
| Charles R. (C. R.) Oldham     | NCA Commission on Schools        |
| cro at nca.asu.edu               | Arizona St. Univ., PO Box 873011,|
| V:480/965-8700 F:480/965-9423 | Tempe, AZ 85287-3011           _ |
| "I like it!"--Citizen G'Kar   | #include <disclaimer.h>       X_>|