cron runs in UTC time not local time

dragonbite

dragonbite

(first off, "Hi", this is my first post here though I am active in a few Linux forums):beer

I have a FreeBSD 8.2 web server that a co-worker set up. I am trying to get cron to run a script I have which takes a text file (a database query uploaded by another server) and puts the data in the proper PostgreSQL database, emailing me if there are any errors.

What I have found is cron is running on UTC time, not local time. So setting the crontab to run at 5:30 AM results in it running 5:30 UTC, or 12:30 AM local time. This ends up updating the database before the new text file is uploaded!

Is there a way to have it run based on local time either for [1] the specific job, [2] specific user or [3] globally?

I could take the cron job and set it to <desired time> + 5 but then there is daylight savings time and coordinating to make sure the other server uploads the text file early enough to handle the fluctuation.

Thanks for any help!
 
Read adjkerntz(8)() and also show your relevant entries to /etc/crontab.
Code: 
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31    0-5     *       *       *       root    adjkerntz -a
That means you would probably have to disable this.
 
The adjkerntz(8) page states
If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time (MS-DOS and MS-Windows compatible mode). If that file does not exist, it means that the CMOS clock keeps UTC time.
Click to expand...

I took a look and /etc/wall_cmos_clock exists, so the CMOS clock should be keeping local time

My current time shows
Code: 
$ date
Tue Nov 27 11:45:39 EST 2012
$ date -u
Tue Nov 27 16:45:41 UTC 2012

I've been trying different things, such as setting in crontab, but this didn't change anything
Code: 
TZ="America/New_York"
I also tried TZ=EST but I am thinking this may be something Linux-related.

So the important bits of crontab are
Code: 
#Turn off automatic CRONTAB email and let the individual proccesses handle mailing.
MAILTO=""

# You can use $HOME to specify the home directory instead of the full path

# run update script 5:30 AM, messaging and mailing handled by script
30 5 * * * $HOME/updatedb.sh &>/dev/null

The code does work.
 
Tue Nov 27 11:45:39 EST 2012

Tue Nov 27 16:45:41 UTC 2012
Click to expand...

Separate issue (maybe not) but, the two times are (41-39) 2 seconds apart. You should add ntpd to the rc.conf and configure ntp.conf.

You do realize that the CMOS clock should be set to UTC and that the system will take care of <localtime>? If you decide to "convert" you will need to reset the CMOS to UTC time in BIOS setup and then make the adjustments to system (# sysinstall will help you here). Please google that, because I don't know which one should be done first.
 
beeblebrox, the 2 seconds skew are probably because it took OP 2 seconds to run the second date(1) command. It is not rational to have different seconds on your locatime with respect to UTC, since the difference granularity between them is counted in hours. NTP is a different matter, unrelated to this time skew.
 
The clock is set by ntpd according to the system administrator, but he doesn't know why cron is using UTC time instead of local time (he thought cron runs local time by default).

I am not sure how to check/verify ntpd is running (would that be under "top" or "modprobe"?)
 
# sysinstall will help you here
Click to expand...
Well you see: # sysinsall then -> Index -> Time Zone will give you.
Is this machine's CMOS clock set to UTC? If it is set to local time,│
│ or you don't know, please choose NO here!
Click to expand...
Look in you BIOS CMOS clock. If it is NOT set to UTC; then there are more problems that you are aware. Otherwise you can modify the BIOS CMOS to UTC and convert everything to "proper".
WARNING: A good "conversion" has steps and I did not take notes so you need to look that up.
 
Thank you all for your patience.

I am not sure how changing the CMOS clock to UTC will change CRON to using Local time.

When I ran tzsetup and selected "No" it went through asking for my time zone but that has already been set up to EST (as the date output shows).

Would selecting "Yes" change that to CMOS and would it then throw the local date out of whack because instead of it being 14:35 UTC (9:35 local) it would be 9:35 UTC (4:35 local)?

I'm sorry, I just don't see the thought process.
 
Did you read adjkerntz(8)() ?
The adjkerntz utility maintains the proper relationship between the kernel clock, which is always set to UTC, and the CMOS clock, which may be set to local time.

If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time. If that file does not exist, it means that the CMOS clock keeps UTC time. The adjkerntz utility passes this state to the machdep.wall_cmos_clock kernel variable.
Click to expand...
I think it would be worth your effort to fully look into how this command / utility works.
 
The adjkerntz utility maintains the proper relationship between the kernel clock, which is always set to UTC, and the CMOS clock, which may be set to local time.
Click to expand...

I see two options that either synchronizes from local to UTC ( -i) or UTC to local ( -a). I already have adjkerntz installed and running in the crontab (code below), updating the local time from the kernel (UTC) time and adjusting for daylight savings time.

Code: 
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31    0-5     *       *       *       root    adjkerntz -a

It also appears that since adjkerntz is running that the kernel clock is running UTC.
The adjkerntz utility clears the kernel timezone structure and makes the kernel clock run in the UTC time zone.
Click to expand...

So if I remove adjkerntz then the kernel clock could be running local time instead of UTC, and that is the time cron uses? Is that what you are thinking?
 
t1066 said:
Just two questions.

What does

$ ps aux | grep adjkerntz

show and when did the daily security check run?
Click to expand...

$ ps aux | grep adjkerntz
did not return anything. If I run it a second time it just shows me grepping for it.

I am not sure, what you mean by "daily security check"?
 
My system shows

Code: 
$ ps aux | grep adjkerntz
root         169   0.0  0.0    9920      0 ??  IWs  -            0:00.00 adjkerntz -i
$ ps aux | grep cron
root        1425   0.0  0.0   14124    408 ??  Is   14Oct12      0:22.96 /usr/sbin/cron -s

You would notice that adjkerntz start earlier than cron. Maybe you can run

# service adjkerntz restart

to see if this will solve your problem.

By security check, I mean the two emails that root receive daily.
 
Thank you all! It appears to have been solved!

I was looking online and ran across this thread : http://forums.freebsd.org/showthread.php?t=18780 and the last line gave me an idea so I tried it.

I restarted crond with
Code: 
/etc/rc.d/cron restart

I don't know if the cron job last started when the server was all-UTC and now that the timezone is established and it was restarted it is grabbing the local time, or what.

Thank you for your patience and your help. My apologies if this was suggested before and I didn't understand or it didn't hit me (sometimes I need a baseball bat in the side of the head).

Either way this has been a learning experience. Now I have to figure out how to mark this thread as solved.
 
dragonbite said:
I restarted crond with
Code: 
/etc/rc.d/cron restart
Click to expand...

Doh! I had this issue now and I was not able to figure out why was cron behaving the way it was - everything is set properly and yet cron was executing scripts in weird time (+1h as I am GMT+1). I guess sometimes did you try to turn it off and on again is the way to go :)
 
That's part of Microsoft's 4 "R"s of troubleshooting...

"R"estart the application
"R"estart Windows
"R"einstall the application
"R"einstall Windows

and my preferred fourth "R"

"R"eplace Windows with something else!
 
dragonbite said:
"R"eplace Windows with something else!
Click to expand...

:) .. but over these years I can tell you sometimes I'd rather see Windows server than Linux one (preferably HPUX/Solaris/FreeBSD though). But not to start a flame or anything; my opinion only.

This cron thing is weird. I did a setup of this server at home, synced all pools and later moved it to DC. There were several reboots (power offs) of this server with a proper timezone set (and clock was always UTC). So I don't get it why actually restart of the cron helped. I guess I'll find out next downtime I'll have.
 
You must log in or register to reply here.
Back
Top