UNIX for Dummies Questions & Answers

RHEL AS 3 running on x86 hardware. That have been patched for DST but did not change a few weeks back when time changed over.

Explanation of the issue from another party.

The servers in questions maintain their TOY clock local time instead of
UTC. As by defined functionality It prevents NTP from properly setting the
Daytime shift. It also causes incorrect time set after recycling. If not
fixed it will persist after each reboot.
NTP system starts up with the value set in TOY clock, then it reads value
from the reference server and if the difference exceeds 1000 seconds it
gives up and quits. To maintain time synchronization and NTP functionality
we need adjust the system statement of hardware clock's to use universal
time.

Does this mean I need to set the hwclock to utc time and restart ntp in order to fix? That's what this passages suggests, but I'm not sure. Can anyone clarify.

There is an internal system clock which is the number of seconds since the epoch and this does not get adjusted for DST. Is is right? Compare the output on a broken and working system of:
perl -e 'print time(), "\n" '

If both systems agree of the second but disagree on the representation, then one must not be patched properly or the systems are set to use different rules. That is controlled by /etc/localtime or maybe the TZ environment variable. Is that the same on both systems? Note that if your systems were up and running during the DST transition, the seconds as returned by that perl command would not suddenly change by one hour. What should change is that a different rule would now come into play about how to display the time in human readable form.

If the seconds on the internal system clock is off, then you need to look at how the system clock is set on both systems. This is the issue that your other source was probably thinking about. At boot time the system clock is initialized from the hardware clock that runs all the time via battery. You can keep in local time if you want, but it must be adjusted for DST. Linux can be set to read it and accept it. This works well when you have two OS's on the same box. Linux assumes the other OS set the clock. But for your hardware clock to cause a problem, you would need to reboot the server so it rereads the hardware clock. Or you would need to to be explicitly reading the hardware clock somehow. If linux is the only os on the box, the hardware clock really should be set to UTC (incorrectly aka GMT).

You could also be using NTP. Are you? If so, very early in the startup scripts you should get the time from an NTP server. Then the time on the hardware clock should irrelevant since it is quickly overwritten. In this case, you have an NTP problem somehow.

Be sure to read: https://www.unix.com/tips-tutorials/3...mekeeping.html

Doesn't redhat have a dateconfig (or maybe date-config) tool? If you have that, compare the settings on both systems. Otherwise check /etc/sysconfig/clock on both systems.