Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
cancel
Showing results for 
Search instead for 
Did you mean: 

Time difference in kernel logs

SOLVED
Go to solution
Bohus Plaucha
Occasional Visitor

Time difference in kernel logs

Customer question: We need to know how to PROPERLY set the system time in IPF console and/or in Linux operating environment so that the time AFTER booting the Linux kernel (between actual boot and entering runlevel 3) was in our local time zone. Right now, after kernel boots up its time is in GMT timezone. We have checked that the time in IPF console is set correctly to our local time.
(Platform: RHEL4/U5 on IA64 - rx6600)
3 REPLIES
Stuart Browne
Honored Contributor

Re: Time difference in kernel logs

It sounds like you are using the wrong '/etc/localtime' file.

Use the 'timeconfig' command to select the right zone. If that fails, try using the 'tzselect'.

If both of those fail, you can manually copy the '/usr/share/zoneinfo//' over your '/etc/localtime' file.
One long-haired git at your service...
Juraj Lutter
Occasional Visitor

Re: Time difference in kernel logs

No, the problem is that the time is incorrect BETWEEN the kernel boot and entering of runlevel 3. Sound to me more like a initrd issue -> the kernel does not have proper timezone at the time when initrd gets loaded. I suppose this is more an initrd issue. Once the system enters apropriate runlevel and timezone is being set from /etc/sysconfig/clock file the problem diminishes.
Matti_Kurkela
Honored Contributor
Solution

Re: Time difference in kernel logs

In Linux, you can choose whether the OS expects the hardware clock to be in UTC time or in local time. Note that the hardware clock is separate from the OS clock: hardware clock is a battery-operated chip that keeps running while the system is powered down, but the OS clock is a software-generated thing.

Look into file /etc/sysconfig/clock. If it has a setting UTC=yes or UTC=true, the OS expects the hardware clock to be in UTC time. This is RedHat-specific.

The same information is also stored in another place: the third line of /etc/adjtime will say either "UTC" or "LOCAL".

To be completely sure, keep both settings in sync.

First ensure your system timezone is set correctly. Then set the OS clock to correct time (either using "date" to set time manually, or "ntpdate" to get the time from a NTP time server).
Edit /etc/sysconfig/clock to match what you want, then copy the correct time from the OS clock to the hardware clock with:

hwclock --systohc --utc

if you want to use UTC time, or

hwclock --systohc --local

if you want the hardware clock in local time.

The "hwclock" command will automatically update the /etc/adjtime file.
As the last step, update your initrd so that the changed settings can take effect in the earliest boot phases.

If you set the hardware clock to UTC time, that is what the IPF console will show.

The start-up scripts of Linux will use the hwclock command to copy the hardware clock time to the OS clock. This happens very early in the boot-up sequence; if I recall correctly, it is done before even the root filesystem is checked & mounted. So the possibility of "wrong time" is meaningless, as the system is prevented from writing the wrong time information anywhere. This is also the time when the kernel's internal timezone information is set. Read the NOTES section on "man hwclock" for more information.

Generally, keeping the hardware clock in UTC time is the better option of the two. It allows the system to handle Daylight Saving Time changes flawlessly in any situation, whether the system is running, shut down or happens to crash at the exact time of the DST change. The only requirement for this is that your timezone settings are correct and up to date.

MK
MK