Bug? Problem with Directadmin or cron's time != server time

[Jing]

Hello, I have recently noticed that my cron usually runs 10 hours earlier (or 14 hours later) than the specified time. Instead of every 23rd hour of the day, it was executed at 13th hour of the server time.

I looked into the cron's logfile, and realized that while the crons were executed at the right time (by directadmin's standard), they were not the same time as the server. Ie Directadmin seems to be running on a different timezone for some reason. I found out about the time discrepancy because my cron was recording the time updated to a mysql database, and I was reading through the log on the database.

I did a further investigation to make sure that the time discrepancy wasn't due to any mysql problem. For example, right now it's only 14:34, and the cron for 23:51 was already executed at 13.51. In the cron log however, it is recorded as being executed at 23:51. Now while it is supposed to be 14.34, somehow in the cron log, the day has just begun at around 00:34.

In case I am confusing anybody, let me try to make it simpler.

Time now = 14.34.
Server time = 14.34.
Cron's log time = 00.34.

Cron was supposed to be executed at 23.51 server time.
But it was executed at 13.51 server time.
However, 13.51 server time shows at 23.51 in cron's log.

I have checked that the server time is accurate. So the only thing left now that may be of problem is Directadmin or the cron daemon and if either of them uses internal clock. I have see that there are at least two other people in this forum having similar problems. Their threads however give no information.

Anyone has any ideas if this could be a bug?

 

[floyd]

How does the hardware time compare?

 

[nobaloney]

We run our servers' hardware clocks on UTC (Coordinated Universal Time), and have so designated in each system upon system setup. We run local time on each server as requested by the user who rents the server. We've never seen this problem.

We use CentOS and I have no idea where it keeps the setting for UTC; we've never had a problem so we've never looked.

Jeff

 

[Jing]

How does the hardware time compare?

How do I check the hardware time? I'm on freebsd 6.3. I can't find any freebsd's equivalent of hwclock. Or is there only way around this to reboot the server?

We run our servers' hardware clocks on UTC (Coordinated Universal Time), and have so designated in each system upon system setup. We run local time on each server as requested by the user who rents the server. We've never seen this problem.

We use CentOS and I have no idea where it keeps the setting for UTC; we've never had a problem so we've never looked.

Jeff

Hmm... I am not sure what settings have my provider configured the hardware clock on. This is a relatively new box that I started working on a couple weeks ago. The time discrepancy may very well has been there since day 1. But I have never really paid attention until recently when I started putting stuff onto the server.

I think there are more users being affected by this. Some of them that I came across have problems with exim instead of crons. Or maybe I do have problems with exim timestamping a wrong time too, I just don't use it. Hardware clock being out of sync seems to be a reasonable explanation. Now I just need to find out how to check the clock in freebsd.

 

[nobaloney]

I don't know if FreeBSD and other BSD solutions even understand the concept of setting the servertime to UTC working differently than not. The reason linux does is historical:

When Linux was first built, most users shared it on a MS/Linux system. If you set the system (hardware) clock to your local time you'd expect the MS operating system to switch between Standard Time and Daylight Saving Time. If you set the system clock to UTC you'd expect Linux to do the switching.

But today I can only write about what I use, which is Red Hat and CentOS servers, and Mandriva desktop systems.

Jeff

 

[Jing]

I just want to come back to this thread to post that I have solved my problem and hopefully someone else would find this thread useful.

I did a lot of things, like using date to change kernel or hardware time, then using tzsetup to adjust the kernel time again etc. My final set up was making the hardware time being UTC, and kernel time being localtime.

However, I don't think that most of what I did previously even matter because I tried and I checked and cron was still working at the wrong hours. Then I restarted cron and everything works fine at the right hours after that! It is just so simple!!

I suppose that after I receive my server, setting up the timezone and everything, cron never picked up the new time settings. The 10 hours lacking behind problem is probably because it was still using the old time settings.

So yea, if you are having the same problem. Restart your cron via "/etc/rc.d/cron restart".

Took me ages to research on this. Not exactly common, but I was managed to get some clues from a few cases through google.

 

[nobaloney]

Interesting. And I bet this is why our linux desktops pop up Kalarm one hour off the right time when Daylight Saving Time begins/ends. Have to try it this fall.

Thanks!

Jeff