Red Hat Enterprise Linux time question

Tom Dunne

As you may have gathered from my previous posts in this forum, I am far from a Linux System Admin, but I find myself doing the odd bit as part of my day to day job.

Briefly, we have five identical machines, running RHEL 4, but one one machine, the system time is an hour behind.

I know I can change the time using the date command, but I would rather figure out what is different on that machine so I won't face the same problem in March when the time goes forward. Also, it's a live database server, so I am reluctant to change it without pointing the users over to one of the other systems.

So, where do I start?

Jackz

Perhaps the other 4 servers are configured to use ntp? And regularly check with a time server to see what the right time is.

You can check this by:

#ps -ef | grep ntp.


Also it might be set to UTC as Db Servers often are.

#cat /etc/sysconfig/clock on the servers.

Tom Dunne

Jackz wrote: »

Perhaps the other 4 servers are configured to use ntp? And regularly check with a time server to see what the right time is.

You can check this by:

#ps -ef | grep ntp.

Hmmm, no ntp running on any of the machines.

Jackz wrote: »

Also it might be set to UTC as Db Servers often are.

#cat /etc/sysconfig/clock on the servers.

Output of above is:

ZONE="Europe/Dublin"
UTC=false
ARC=false

Where to next?

On a side note, I see Oracle do a "Managing Oracle on Linux" course I might do.

Red Alert

My guess is someone probably changed the time manually, so the BIOS clock (which Linux will set to UTC regardless of time zone) is probably off by an hour.

ntlbell

Tom Dunne wrote: »

As you may have gathered from my previous posts in this forum, I am far from a Linux System Admin, but I find myself doing the odd bit as part of my day to day job.

Briefly, we have five identical machines, running RHEL 4, but one one machine, the system time is an hour behind.

I know I can change the time using the date command, but I would rather figure out what is different on that machine so I won't face the same problem in March when the time goes forward. Also, it's a live database server, so I am reluctant to change it without pointing the users over to one of the other systems.

So, where do I start?

Setup ntp on all machines

problem solved..

if it is setup maybe there's a problem with the drift file..

Tom Dunne

Red Alert wrote: »

My guess is someone probably changed the time manually, so the BIOS clock (which Linux will set to UTC regardless of time zone) is probably off by an hour.

Believe me, there is nobody capable of that. I am supporting machines for a client of our company.

A recent quote by one of their employees: "Those things run a weird version of windows or something, don't they?".

ntlbell wrote: »

Setup ntp on all machines

problem solved..

if it is setup maybe there's a problem with the drift file..

Not really an option. I'm a DBA, not a sys admin, so I wouln't have the skills to do it.

ntlbell

Tom Dunne wrote: »

Believe me, there is nobody capable of that. I am supporting machines for a client of our company.

A recent quote by one of their employees: "Those things run a weird version of windows or something, don't they?".



Not really an option. I'm a DBA, not a sys admin, so I wouln't have the skills to do it.

if you can follow very straight forward screen shot to tick a box

you can do it who said DBA's were only good for cleaning ashtrays

here

if you do a quick google you will find local tim servers TCD has one for example use those instead of the ones in the example :P

time servers here

ressem

Red Alert wrote: »

My guess is someone probably changed the time manually, so the BIOS clock (which Linux will set to UTC regardless of time zone) is probably off by an hour.

That's not quite right.
If you read through the \etc\rc.sysinit script, you'll see that linux sets the clock by running hwclock with either the flag --utc or --localtime.

--localtime indicates that the BIOS clock should always be set to the operating systems local time. The operating system is expected to adjust this. This is indicated by the UTC = no in /etc/sysconfig/clock. It's recommended for systems that dual boot to windows.

--utc indicates that the BIOS clock should not be adjusted to account for timezone and daylight savings time by the operating system.
Instead the OS is entrusted to to add the timezone and DST to any application that asks.
This is indicated by the UTC = yes in /etc/sysconfig/clock.

As mentioned above, having UTC = yes is often recommended for linux servers.

----

The issue is likely to be a misunderstanding in UTC, and daylight savings flags when setting the clock.

When putting the date in, note that you should provide the local time rather than the UTC time to the date command.

change /etc/sysconfig/clock
UTC=true

date 12051835
hwclock --systohc

Tom Dunne

ntlbell wrote: »

if you can follow very straight forward screen shot to tick a box

Well, first things first, I only have remote access, so none of your fancy gui's. Yes, I know it can most likely be done at the command line too.

Secondly, I can't justify through the Change Control process, the changing of four production machines for the sake of one. I would rather change one, to make it like the other four.

ntlbell wrote: »

you can do it who said DBA's were only good for cleaning ashtrays

Excuse me. We can make the tea too.

ntlbell

Tom Dunne wrote: »

Well, first things first, I only have remote access, so none of your fancy gui's. Yes, I know it can most likely be done at the command line too.

Secondly, I can't justify through the Change Control process, the changing of four production machines for the sake of one. I would rather change one, to make it like the other four.



Excuse me. We can make the tea too.

NTP should be standard on all servers this should be part of the base install's ongoing so there's not need for change control requests etc

it's the only real way to guarantee all machines keep the exact time...

if it's not done now instead of one problem you will more than likely have four problems further down the road anyway

I'm always amazed that a place has gone to the bother of creating a change control process yet they place no importance on basic configuration of production servers.

Truly bizzare....

It's like someone spending a month writing a policy on secure passwords and the policy is everyone uses "password"

Tom Dunne

ntlbell wrote: »

if it's not done now instead of one problem you will more than likely have four problems further down the road anyway

But as I see it, now they have four correctly configured machines, that change time when they are supposed to, and one that does not. So there are four working, one not, I would like to fix the not working machine.

ntlbell wrote: »

I'm always amazed that a place has gone to the bother of creating a change control process yet they place no importance on basic configuration of production servers.

Truly bizzare....

Don't get me started - I had to submit a change request the other day when, in the course of investigating the time problem, I discovered that the root password on all five machines was set to 111111. :eek:

dubhthach

Could it be that 3 of the machines are set to DST (daylight savings time) and the other to UTC?

You can change the default timezones using tzconfig (check the manpage: man tzconfig -- it should be installed but I haven't played with RHEL in awhile)

In my last company we defaulted all our Debian webservers to UTC so as to avoid issues with DST (US starts DST before Ireland etc.)

What is UTC, and what is a DBA?