crontab - wrong time zone

[Stephen Badgett]

How do I get crontab to use our TZ correctly without manually calculating a 3 hour time difference?
----------------------------------------------
I have a simple test crontab job

2 16 * * 2,3,4,5,6 ll >/tmp/TIMEZONE.log

This is to run @ 4:02 pm as shown here but, the crontab job here ran Wed Feb 9 13:02:02 PST 2005

ll TIMEZONE.log |cut -b 35-
7429 Feb 9 13:02 TIMEZONE.log

echo $TZ
PST8PDT

[Florian Heigl (new acc)]

My cron respects the timezone, so I could only guess that Your timezone is not set in /etc/TZ but defined somewhere else.

Check what's inside /etc/timezone, if that's ok I don't know where else to look.

[A. Clay Stephenson · Accepted solution]

I suspect what has happened is that /etc/TIMEZONE was edited after the cron daemon started.

cd /sbin/init.d
./cron stop

./cron start

[Stephen Badgett]

cat /etc/TIMEZONE
TZ=PST8PDT
export TZ

and I have noticed a /etc/default/tz

cat /etc/default/tz
EST5EDT

would this have an affect?

[Stephen Badgett]

I will try a cron stop and start.

[Stephen Badgett]

I did a stop/start of cron and the affect is still the same.

[A. Clay Stephenson]

The answer is still the same but there is a gotcha. All of the scripts under /sbin/init.d are run by rc and rc is responsible for reading /etc/TIMEZONE. If that value is not found, it defaults to the timezone value defined in the kernel. Man 4 rc.config for details.

This procedure should work: Make sure that TZ is set and exported as the current user, root. Now bounce the cron daemon. The bad news is that cron should really never exit so cron shouldn't really be bounced; the really "correct" procedure is to reboot after making certain that /etc/TIMEZONE is valid.

[Stephen Badgett]

I bounced the machine after making sure the TIMEZONE file was correct and I believe it was ...

TZ=PST8PDT
export TZ

I still get the same results, I am stumped for now.

[A. Clay Stephenson]

This one is very strange. I would look for and apply the latest cumulative cron and rc patches. One thing that might have happened is that someone "improved" the rc.config or rc script so that /etc/TIMEZONE is not actually sourced. I would also be interested to know what the kernel's timezone tunable is set to. I'm betting it's set to 300 and that value is what is winning but /etc/TIMEZONE should override it.

[Fred Martin_1]

Had a similar problem once on a Linux box, and it turned out there was a bogus time zone file someplace and just happened to be on the PATH before the real one.

However - the entire server's time was off not just cron.

Not sure if this applies to your situation.

[Stephen Badgett]

Thank you for your help.

The tunable for timezone is 420

I looked through the rc script and found the TZ=EST5EDT -- I will change it there and see if that makes a differance.

I will also look at the path and see if there is something that might be changing it.

[A. Clay Stephenson]

The "TZ=EST5EDT" line is /sbin/rc is there to set a default value in case /etc/rc.config or /etc/TIMEZONE are not found; if changing this line changes the behavior of cron then you have narrowed the problem but it does not explain why cron uses it when you explicitly execute /sbin/init.d/cron start after setting and exporting TZ. Something that would explain all of this is if someone has improved the "/sbin/init.d/cron" script itself and defined TZ inside it. Since it's possible that someone has improved things for you, I would also make sure that the symbolic links in /sbin/rc1.d and /sbin/rc2.d point to the cron script in /sbin/init.d.

[Stephen Badgett]

I looked through the /sbin/init.d/cron script - rather short - and found no TZ information in it and compared the file on a different machine they just a like too.

The Symbolic links are there too...

sbadgett:HAL: /sbin/rc1.d> ll -u |grep cron
lrwxr-xr-x 1 root root 17 Feb 11 16:23 K270cron -> /sbin/init.d/cron
sbadgett:HAL: /sbin/rc1.d> ll -u /sbin/rc2.d |grep cron
lrwxr-xr-x 1 root root 17 Feb 11 16:24 S730cron -> /sbin/init.d/cron
s

We are going to boot the machine again after running "set_parms timezone" and I am not sure this will help since the TIMEZONE file was already set correctly.

[A. Clay Stephenson]

Just because you didn't find any TZ's in /sbin/init.d/cron doesn't mean they aren't there. You also need to look for any "." (dot) operators which would source other files. For example, this script sources /etc/rc.config.d/cron via "." and someone mighr have "improved" this file beyond its normal role of simply deciding whether or not cron shpould execute. One other crazy thought is have you done "a ps -ef | grep cron" to see if only one cron daemon is running?

[Stephen Badgett]

I have gone through the /sbin/init.d/cron file and looked for any sourcing and only found the /etc/rc.config.d/cron that allows cron to be loaded. CRON=1

I also do a ps -ef |grep -i cron and oly found the one /usr/sbin/cron running.

[A. Clay Stephenson]

I'm about out of ideas. Again look from cron patches and check /usr/lib/tztab. Cron accesses this file and it's just possible a bogus entry in this file is the culprit. I would also launch a script under cron and have it output the date command. This would tell you what TZ thinks it is --- although off the top of my head, I don't think TZ is exported to the cron'ed process.

[Bill Hassell]

You may need to instrument the rc scripts that start prior to cron. Use logger to put the state of TZ into syslog (rc scripts are run differently than a login). Put a line like this at the start of each script preceeding cron:

logger -t "$0" -p local1.info "TZ=$TZ"

Now in syslog (after reboot), you can see where TZ changes value.