The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Server Time Issue

Discussion in 'General Discussion' started by sallen812, Feb 4, 2008.

  1. sallen812

    sallen812 Member

    Joined:
    Oct 20, 2005
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    1
    I have a server with a timing issue, it's hanging up some software.
    Here is the basic server set up

    WHM 11.15.0 cPanel 11.17.0-R19434
    CENTOS Enterprise 5 i686 on standard - WHM X v3.1.0
    Operating System: CentOS 5
    Apache version 1.3.39 (Unix)
    php4 and php5 enabled
    CPU: Core 2 Duo - 2.66 GHz
    RAM: 2 gigs
    HD: 120 gig

    I have to admit it makes my eyes roll back in my head. If this were your server, what would the corrective action be?
    How would you communicate what actions needed to be taken to correct this timing issue?

    Does any one understand what is going on? (read section below)

    Here is the Problem.

    Hi Steve-
    That's a strange problem. I went ahead and installed a small test CGI script on the server.

    That tests a few simple time functions. It appears that there's a problem with how the basic system calls to report the dates and times on that server are working. In that output, you'll see this:

    Time::Local version: 1.11
    UTC time: Mon Feb 4 19:34:25 2008
    Time, as seconds since epoch: 1202153688
    After converting back w/Time::Local::timegm: 1202153665

    Off by 23 seconds.

    For some reason, the sever's code is off by 23 seconds - which is very odd.

    This discrepancy is what's causing the problem in the calendars. Do you know anything about this server, like what OS it's running? You may want to ask the hosting company about this, probably send them that URL and ask if they can fix that.

    They can take a look at the source of that test script, and/or I've attached that here, they'll probably want to see it. I really don't know what would cause this, it's a pretty basic set of time operations. (The test just gets the current time in the system 'epoch' format, converts that to UTC time, then back to the 'epoch' form. Results in the 23 second difference, which shouldn't happen.) Feel free to have them contact me directly if they like.
    -Fred


    Text Attachment [ Scan and Save to Computer ]

    #!/usr/bin/perl
    use strict;
    use lib '.';

    use Time::Local;
    use CGI;

    my $isCGI =($ENV{HTTP_HOST} ||
    $ENV{GATEWAY_INTERFACE} ||
    $ENV{USER_AGENT} ||
    $ENV{REQUEST_METHOD});

    my $c;
    if ($isCGI) {
    $c = CGI-]new;
    print $c-]header, $c-]start_html;
    }

    print "Time::Local version: ", $Time::Local::VERSION, "\n", ($c and
    '[br]');

    my $x = time;

    print "UTC time: " . scalar gmtime ($x);
    print "\n", ($c and '[br]');

    print "Time, as seconds since epoch: " . $x;
    print "\n", ($c and '[br]');

    my $y = timegm (gmtime ($x));
    print "After converting back w/Time::Local::timegm: $y";
    print "\n\n", ($c and '[br][br]');

    print "Off by " . (scalar ($x) - $y) . " seconds.\n"
    if ($x-$y);

    print $c-]end_html if $c;


    The software that this is affecting is called calcium, a calendar system made by brownbearsw.com. Its a cgi script that has run on every server but this ine.

    Thanks Steven
     
  2. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Since it's using the system time for both calculations, the discrepancy suggests a bug in the Time::Local perl module. I'd suggest upgrading Time::Local as it appears you have a very old version installed (the latest on cpan.org is v1.18):

    /scripts/perlinstaller --force Time::Local
     
  3. sallen812

    sallen812 Member

    Joined:
    Oct 20, 2005
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    1
    Got some info on this problem and it is specific to Centos 4/5

    There is indeed a problem with the clock or something on that system; it has a 22 or 23 second difference between local time and UTC time:

    [sallen@server ~]$ date; date -u
    Tue Feb 5 08:40:30 PST 2008
    Tue Feb 5 16:40:53 UTC 2008

    Aha! Found something on this. Haven't read it yet, but it describes the problem:

    http://support.ntp.org/bin/view/Support/TimeScales
    I have printed out the link below. Please read.
    15. Time Scales
    There are two primary time scales used today, TAI and UTC.

    As of 2006, TAI is ahead of UTC by 23 seconds. This is really not true, but somebody else is going to have to document why the answer is really 33 seconds but we only see 23 of them. The simplistic, short (and possibly true) answer is that the "extra" 10 seconds happened before 1972, and computers mostly don't worry about tracking seconds before 1972.

    If you run the date command on a system that is synchronized with NTP and the time appears to be 23 seconds off, the odds are good that your time is being reported using a TAI (right) timescale instead of a UTC (posix) timescale.

    Unix-like systems (for example) generally have timezone files in them, and in most cases the UTC (posix) versions of these files are used.

    Many Linux systems, however, are built so the TAI (right) zoneinfo files are used. If this is the case, you will see the leapsecond discrepancy (in addition to any timezone correction) if you type date ; date -u at a shell prompt.

    Recent versions of CentOS Linux (Release 4 & 5) and Red Hat Linux (Enterprise 4 & 5) may be configured for POSIX time zones as follows.

    A system's time zone may be changed by linking or copying a time zone file in the /usr/share/zoneinfo directory to /etc/localtime. As an example, to specify the POSIX US Eastern time zone use the command:

    ln -sf /usr/share/zoneinfo/posix/US/Eastern /etc/localtime
    or, alternatively, simply copy the file:

    cp /usr/share/zoneinfo/posix/US/Eastern /etc/localtime
    Also, the /etc/sysconfig/clock file should be edited to specify the correct time zone and change the UTC line to either UTC=true or UTC=false as appropriate. As an example, for the POSIX US Eastern time zone the /etc/sysconfig/clock file should read:

    ZONE="posix/US/Eastern"
    UTC=false
    ARC=false
    The time zone that is currently being used is specified by the /etc/localtime zone file whereas all of the generic time zone files reside in the /usr/share/zoneinfo directory. Specifically, the POSIX zone files are stored in the /usr/share/zoneinfo/posix directory.

    Configuring the time zone in versions of Linux other than CentOS and Red Hat should be very similar to the above.
     
  4. sallen812

    sallen812 Member

    Joined:
    Oct 20, 2005
    Messages:
    14
    Likes Received:
    0
    Trophy Points:
    1
    The above fix did the trick. changing the server from TAI (right) to UTC (posix) fixed the offset.
     
Loading...

Share This Page