NTP issue on N4000 server (lost 90mins of time)

[chris wright_6]

Enviroment : 4 N4000 servers in service gaurd cross site cluster, Identicle Hardware / Software.

Issue :
NTP was woring with no issues, slewing was working all boxes were within a second of each other. I brought down 1 box for maintenance (disk swap) on bringing the box back up the time on the box was 90 mins out, the same time the box was down for ?, ntpd would not start due to the time being to great a difference, I change the time to within 2 seconds and re-started ntpd time is now fine.

Question : Why would the time go out by the 90 mins, the box was not powered down, i thought there was an internal clock/battery that kept the time upto date the time was definately ok before shutdown.

Any help with this would be great

Rgds
Steven

[Pete Randall]

Dead battery?


Pete

[chris wright_6]

Pete,

Thanks for that,


I thought the GSP battery only kicked in if power is taken from the box, on that basis what is the internal battery actually used for

cheers
steve

[Steven E. Protter]

Shalom,

If ntpd failed for some reason there is a message in /var/adm/syslog/syslog.log

You may wish to periodically route the output of ntpq -p to your own log file to see if you spot this problem developing.

You of course know that ntp can only correct the clock a certain number of minutes, beyond that you must manually adjust the clock to put it into a range that ntpd can deal with.

Pete is likely correct, a battery problem can cause this. If its really dead, it can lose its time during boot.

SEP

[chris wright_6]

Thanks guys,

Im missing something fundamental here,

why would the time be effected by the battery when power was not taken from the box, isnt the battery there to be used when the box has no power running to it.

In my case the box was put into maintenance mode for 90 mins then booted, at no point was the power disrupted, so why would the battery be used. ?

[Pete Randall]

Sorry, I was really kidding when I mentioned the dead battery. I honestly am unable to come up with a theory that would explain this. I tend to think, like you do, that things should have kept on ticking.


Pete

[chris wright_6]

Thanks pete,

you ok with a 0 point score on that one then !!

[Jaime Bolanos Rojas.]

:-)

At least all of you guys got a good sense of humor...

Jaime.

[chris wright_6]

Ye good sense of humour but no bl**dy answer !!!!! haha

ive got a call raised to HP ....in india obviously and there getting no where with it.

honestly any ideas are most appreciated

[Jaime Bolanos Rojas.]

Chris,

If you already check the logs, and nobody stopped the ntpd and nothing appears to be wrong with the system, then I would think about external factor.
How is your ntp server configure, thought serial device, another server?
Whichever is the option of those two, I would think about a network problem maybe.
If a switch is in the middle of the hold thing, maybe a flecky port on the switch, or maybe the external connection drop form some unknown reason.
I would check on those things, probably if it fell behind by 90 minutes is going to do it again. If it does, chances are is a hardware problem and chances are not with your server.

Everything is a possibility here, depending on your setup and if there is nothing pointing nowhere in the logs.

Regards,

Jaime.

[Bill Hassell]

Actgually, it doesn't matter whether the internal clock is running during a shutdown. When your server boots up, the xntpd startup script will 'jump' the time to match the NTP server listed in the netdaemons config file. If this server is broken, the time could be set to any value as there is no reference to compare. That's why your ntp.conf file has 3 to 5 different NTP servers listed. Look at your /etc/rc.log file for any errors related to NTP. Then find the bootup NTP server:

grep NTPDATE /etc/rc.config.d/netdaemons

Now test the server:

ntpq -p ntp_server_name

If this fails (server not responding, blocked, wrong name, etc), then this is why the time jumped so much. It's possible that the internal clock isn't working correctly and the failure of the bootup NTPDATE server has exposed this problem. If the startup NTP server was working, the internal clock's value would not matter and your machine could reboot several times with exact time at startup.