UNIX for Dummies Questions & Answers

This occurs on an i386 box running Unix System V/386 Release 4.2 Ver 1.1.2.

I have an 'at' scheduling anomaly whose behavior I am trying to understand. On one particular system, when an 'at' job is submitted, the time the job is actually scheduled to run is exactly 2 hours later than what the command stipulated. I append the output that illustrates the problem:

-----------------------------
btd33m01!root[9] date
Fri May 13 09:19:42 EDT 2005
btd33m01!root[10] at 09:21
/test.sh

UX:at: WARNING: Commands will be executed using /usr/bin/sh
UX:at: INFO: Job 1115997660.a.0 at Fri May 13 11:21:00 2005
btd33m01!root[11]
-----------------------------

So, at 09:19:42 I submit the 'at' job to run at 09:21, and the system replies "OK, I'll run it at 11:21." The "consistently off by exactly 2 hours" symptom suggests to me some kind of timezone cause.
However, the TZ env var looks the same as the other related systems, none of which display this problem:
TZ=':/usr/lib/locale/TZ/US/Eastern'

Does anyone have any explanation or a suggestion on what else to look at?
Thanks!

I forgot to add ...

Entries in the crontab on that system, run at the correct time.
This symptom affects only jobs submitted using 'at'.

That is a strange one. Here is a totally wild guess. Is it possible the user you are logged into when doing the at command has the TZ variable being set differently in their login scripts (.login, .profile, whatever) than what the default TZ for the system is?

I doubt that would work but I can't think of any other way that symptom would be happening. Try touching a file then look at the timestamp to see if that is two hours off also maybe.

Good luck.

Thanks for the suggestion, but no that can't be the case.
This occurs when logged in as root, which is always the case for us on these systems, i.e. we never log in as anything else.

Use this command to launch an environmentless subshell:
env - /usr/bin/ksh
and try the at command again. Is it still 2 hours off?

Hi, Perderabo -
Your suggestion was helpful! In the environmentless ksh, the at command was scheduled at the proper time. Of course, with no environment vars defined, it used GMT. When I then added only this one env var definition:
export TZ=:/usr/lib/locale/TZ/US/Eastern
the 2-hours-off symptom began to occur in this "stripped down" shell.

I compared this Eastern file to one on a related system (that schedules OK) and the files are identical. I even copied it over from a "good" system to try it, but with no effect. I also tried other TZ files, Central, etc. and, while the time changed, depending on the TZ value, the 2-hours-off symptom persisted.

One detail about TZ I don't understand.
When I assigned this value to TZ (i.e. without a leading colon):
export TZ=/usr/lib/locale/TZ/US/Eastern
the variable seems to be ignored. The at schedule used GMT, as if TZ were not set.
However, if it is set this way:
export TZ=:/usr/lib/locale/TZ/US/Eastern
the symptom always occurs.

So, your suggestion has helped shed a little light on this.
It is somehow connected to the TZ setting, but it's not clear exactly where the problem is. Do you have any follow-up ideas? Thanks!

I doubt that your TZ variable is set correctly. That "related system"...is it running the same OS? And the TZ variable really has that odd value? On the malfunctioning system, try:
/usr/sbin/zdump -v -c 2007 $TZ | tail
and post the results. And try setting
TZ=US/Eastern
and see if the at job still is 2 hours off.