Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

we've been having an issue getting time synced across our Litespeed web cluster, that being that the system time (we're using CentOS) appears to be thinking that the current time for EST (Being the "America/New_York") time zone is 3 hours ahead of current time.

In Florida right now the time is 10:53PM The server reports this: TZ='America/New_York' will be used. Local time is now: Tue Jun 4 01:51:43 EDT 2013. Universal Time is now: Tue Jun 4 05:51:43 UTC 2013.

What would cause something like this? The same is applying in our PHP.ini configuration for the cluster.

This is the response from a perfectly fine web-server which is configured exactly the same: TZ='America/New_York' will be used. Local time is now: Mon Jun 3 22:53:15 EDT 2013.

--Update 1-- ntp peers on a WORKING server:

krillin.ecansol  2 u   52   64    1   35.631  110337. 7937.50
 ntp.sunflower.c 16 u    -   64    0    0.000    0.000 15937.5
 triangle.kansas  2 u   50   64    1   55.125  110331. 7937.50

ntp peers on a BROKEN server:

 fairy.mattnordh  2 u   59   64    7   49.397  -108052   1.171
 ec2-50-16-231-1   2 u   60   64    7   59.565  -108052   0.016
 colossus915.ser    2 u   59   64    7   46.693  -108052   0.051
share|improve this question
Why are any of your servers anything but UTC? – Michael Hampton Jun 4 '13 at 3:02
That really doesn't answer the question, but the reason is that our company operates out of Florida and our payroll system is dependent upon times syncing up with Floridian time (EST) and thus for this special case we need the cluster to serve pages based on EST. – Matthew Salsamendi Jun 4 '13 at 3:08
We'll try to ignore just how screwed up that line of thinking is for a moment and focus on time synchronization. How are your ntpd configured on each server? Are they synchronizing against the Pool? Do they peer with each other? – Chris S Jun 4 '13 at 3:12
I'm not the most experienced when it comes to ntp and the configuration of ntpd, but I have updated the question to contain the peers that our servers are using for both a working and broken server. Let me know what other information you need. – Matthew Salsamendi Jun 4 '13 at 3:52
Er, that's not the configuration data... try /etc/ntp.conf – Chris S Jun 4 '13 at 4:47
up vote 3 down vote accepted

Unless you've specifically configured your OS to expect otherwise, your server's system clock must reflect UTC, not local timezone. Timezone offsets are applied after-the-fact, as multiple timezones can be used at the same time on a single server. Your timezone file tells the server what time to return given the assumption that the system clock is set to UTC.

NTPd will refuse to synchronize if the system clock is too far off the target clock. You have to manually set it to something within a minute or so of the target time (UTC); either that or use ntpdate to fetch the time from an NTP server and immediately set the clock accordingly. Then you can run ntpd to fine-tune your clock to get the millisecond precision you need.

After a warm-up time, ntpq -pn should show one remote server marked with a * on the left to indicate that it has been been declared the primary synchronization peer, with others hopefully marked with a + to indicate that they are qualified back-up candidates for peering.

If not, then your clock is not being synchronized.

Note that in the list of peers, the offset should be less than 1ms [absolute value] in normal running condition, perhaps a few hundred ms as the clock gets fine-tuned. Your list shows an offset so far out of range that synchronization using clock slewing is impossible. Instead, you'll need to "jump" your clock to the correct time, something ntpd will by policy never do on its own. That's what the ntpdate tool is for.

share|improve this answer

Are you running ntpd with the -g option? It should be specified in /etc/sysconfig/ntpd. Without -g, ntpd will refuse to set the clock if it is off by more than 1000 seconds.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.