Weird Behaviour Of Clock On Stevie

[Piotr GRD]

This issue is not in any way critical.

This issue does not affect me, by myself in any way.

But I found it weird...

 

 

If you will try to access Stevie multiple times and look at the current time reported in HTTP headers, you may spot that the time on this server "jumps" back and forward every couple of seconds (or maybe even every second) and the difference is 24 seconds. The time is either correct or 24 seconds behind (and nothing between).

 

 

Previously I didn't spot it ever, every time I was checking it (on my "Server Time Info" page) the time on Stevie was 24 seconds behind. But today I have spot it correct - I though: "Oh! Someone finally have set it up. : ) ". But couple of minutes later - 24 seconds behind, again. "What?...". So I have started to manually check it every 1, 2 or 3 seconds and... surprise.

 

 

There may be something wrong with ntpd on it.

But again: this is not in any way critical issue and does not affect me at all.

I've just spot it and for a case no-one else did - I am posting about it.

[Krydos]

That is interesting.

 

It looks like stevie has a cron job to run ntp, and johnny does not. I'm thinking a cPanel upgrade added rdate and autosyncing of the time, but stevie already had ntp set up and now rdate and ntp are fighting each other.

 

@piotr, thanks for noticing this. I've removed the ntp from cron, and killed the existing ntp process. Both stevie and johnny now have identical rdate calls to the same server. (I assume this line was added by cPanel upgrade anyways.) Let us know if you see anything weird or if this doesn't fix the weirdness.

[Piotr GRD]

Better now. Still weird, though.

 

 

Yesterday time on Stevie was either correct or 24 seconds behind randomly somewhere around 50:50 or maybe 60:40 / 40:60 - I didn't really count it, but have checked manually tens of times (maybe even ~100).

 

 

Today when I've tried the same tens of times (up to ~100, maybe) - time reported by Stevie was usually 24 seconds behind, however couple of times it was correct.

 

So usually it's 24 seconds behind, but sometimes, very rarely it "jumps" and is correct for a moment. As I didn't ever (before yesterday) check it so many times, it's possible that this was always the case for Stevie. Or not, I don't know, I have no any data about it from before yesterday, I can only say that it's possible.

[Guest xaav]

I've removed ntp, so hopefully that will fix the problem.

[Piotr GRD]

No. It's again -24s or correct in the ~50/~50 proportions (based on manual multiple checks, but one could make a bot and log exact results if needed).

 

Just saying, it's not any big problem. Weird one, though.

[Guest xaav]

I can't imagine how this is occurring, since `rdate rdate.cpanel.net` resets the clock to the correct time, and I can't find any other time providers installed.

[Piotr GRD]

I've got some additional info that possibly may give someone an idea of what the reason of this small issue may be.

 

 

Do you remember this topic about server time going back and forward 2 hours?

http://www.helionet....time-of-server/

Well... I was right in my assumptions that these two things may be related.

 

 

 

 

Before I was checking only the time provided in HTTP headers.

And this time - at the moment (2011-12-05) - is 24 seconds behind most of the time, but sometimes it's correct.

 

But now I have started to check also the time displayed with the date/time functions inside of the PHP scripts.

And what?... This time seems to be always correct (seems to be, as I still base only on manual tests done more than 100 times).

 

 

And now the relation between time and default time zone...

• Every time when the time in HTTP headers is 24 seconds behind - the default time zone used in all date/time functions in PHP scripts is set to "America/Los_Angeles" (GMT-8 / PST). The TZ environment variable is empty.
  
• Every time when the time in HTTP headers is correct - the TZ environment variable is set to "America/Chicago" (GMT-6 / CST).
  

There is one more important thing in it.

Not only the time in "Date" HTTP header jumps back and forward 24 seconds.

The time in "Last-Modified" HTTP header (If exists, ie. for static content like *.html URLs) jumps these 24 seconds, too.

 

 

 

So now my assumption is that the clock itself is not desynchronised and don't really jump back and forward. It is synchronised correctly. So you were looking most probably in the wrong place (ntp and rdate).

• Something randomly adjust the -24 seconds offset to the time provided in HTTP headers while keeping TZ environment variable empty;
  
• OR instead keeps the time in HTTP headers without any offset but sets the TZ environment variable to "America/Chicago" (which overrides default time zone used in PHP scripts unless the script itself will set different TZ variable).
  

.