# Hardware Clock [Developer Attention]

## PRC

Ok, so here's my problem:

My clock decides to randomly change. I have tried as hard as I can through simple trouble shooting to make sure its not my CMOS battery, and as far as I'm concerned my time settings in my bios stay between bios boots (stop before linux boot). When I get into linux and boot up linux, the hardware clock changes to some random date, usually only a few months off. 

My question is...

A) Can it still be my CMOS battery?

B) Is there a way to monitor the use of "hwclock" command to see if a nasty script is messing with it?

C) Fixes?

----------

## eelke

Sounds like the same problem I had with my laptop.

The file /etc/adjtime contains information about the hardware clock. Among this information are correction values for adjusting the time received from the hardware clock. If you adjust the hardware clock the wrong way the values can get completely bogus which causes the problem you are having. If I remember correctly it is safe to remove the file. For more information open the man page for hwclock and search for "The Adjust Function".

----------

## PaulBredbury

Use ntp, and set CLOCK_SYSTOHC="no" in /etc/conf.d/clock

----------

## PRC

Yeah, I've been troubelshooting alot and no it's not my CMOS. It has to do with the /etc/init.d/clock script. I am using the newest version of ~baselayout (came out few days ago). I have found that their is something directly or indirectly wrong with it. It could have something to do with the the script not taking /etc/adjtime into account, but lets hope I can tidy up my computer after playing with baselayout and such.

This may be something for some to bug report......

I have solved my porblem, but this brings up a bigger issue: Scripts control over the hwclock.

I don't think a user is given feedback on when a change to the hwclock occurs. A simple yes and no ask should be included in every change of the CMOS/HW clock. This allows a user to allow the HW clock to be constant.  I'm not sure if this is possbile, it most likely is, but I'm not a developer.

 *PaulBredbury wrote:*   

> Use ntp, and set CLOCK_SYSTOHC="no" in /etc/conf.d/clock

 

I think when I set CLOCK_SYSTOHC, that is when things started to really screw up. I was trying to get my HW clock on UTC, for when I travel, and then use KDE to control the timezone change. But hopefully my problem may bring about a change to the clock system.

About NTP, does it require a constant connection, or is it passive to a connection, and will change my clock when it recieves a connection? I want things to alert/ask me when they want to change my clock. Is that to hard to ask?

----------

## CrankyPenguin

I upgraded to the latest baselayout and ended up with a similar problem.  In my case the boot would simply freeze at the point where /etc/init.d/clock was being started.  Botting into interactive mode allowed access to hwclock which ran fine but all attempts to startup /etc/init.d/clock from within that also failed.  

I strongly suspect that the error lies in the lines where /etc/init.d/clock attempts to check for the presence/absence of the Real Time Clock.  My hunch is that this is looking for RTC to be a module only and getting annoyed (freezing) when it appears as anything else (say compled into the kernel.  

The code in question is:

```

 if [[ ${fakeit} -ne 1 && -e /proc/modules && ! -e /dev/rtc ]] ; then

                modprobe rtc &> /dev/null

 fi

```

----------

## jean-michel

I've seen this on a couple of machines (dual opteron boxes, but using x86 NOT amd64 builds), but have no problem on several other systems.  Kind of strange...right now, my workaround is to comment those lines out of /etc/init.d/clock on those machines where it hangs the boot process.

Anyone make any better progress on this.  Compiling rtc as a modules doesn't fix the problem, nor does disabling generic rtc emulation.

----------

## mrsteven

*bump* because this also happens on my system from time to time. It seems like the problem started with kernel 2.6.24 for me.

----------

