at daemon wierdness....

[stanhubble]

Maybe i have been staring at this too long but it doesn't make sense. I have servers across the continent that i wish an "at" job to run on at the same time. sounds simple just use the UTC option in the "at" statement, but it doesn't look right to me.

srv001:~ # date
Tue Feb 21 10:19:27 PST 2012
srv001:~ # at 11:00am UTC < /usr/bin/startsrv
warning: commands will be executed using /bin/sh
job 590 at 2012-02-21 18:00

srv001:~ # date
Tue Feb 21 13:21:32 EST 2012
srv001:~ # at 11:00am UTC < /usr/bin/startsrv
warning: commands will be executed using /bin/sh
job 492681 at 2012-02-21 15:00
srv001:~ #

srv001:~ # date
Tue Feb 21 14:51:45 NST 2012
srv001:~ # at 11:00am UTC < /usr/bin/startsrv
warning: commands will be executed using /bin/sh
job 3257 at 2012-02-22 13:30
srv001:~ #

The offset seems to be backwards. I want the job to run at 06:00 am EST on all servers. Anyone have any ideas as to: what i am doing wrong or an alternate way to schedule to job?

The job needs to be initiated via a consistent shell script.

thx

 

[Noway2]

Maybe I am under thinking what you are trying to do, but from the description it sounds like there are two challenges:
1 - keep the time somewhat synchronized. This can be accomplished by connecting to an NTP server and have the NTP daemon update periodically.

2 - run the scripts at a given time. For this instead of using the at command, have you looked at setting up a crontab entry? You could adjust it with the correct timezone offset for each machine, but with the times set by NTP, they should be executing in tight synchronization. UTC is not the Posix Standard for cron.

 

[stanhubble]

1 - No time is kept properly (ntpd), but the machines are in multiple timezones (time differences in examples is just the difference of when i ran the commands).

2 - not possible because the machines are in different timezones and i want them all to run at 11:00 am GMT or 6:00am EST , individual customization is not an option (300-400 machines)

 

[tarn]

One thing I think it could be but I'm not an expert on AT (in fact only ever used it once about 20yrs ago) ...

Researching the at command I see it should be the format of

# at -t 11:00am UTC < /usr/bin/startsrv

and I don't see you using the -t flag .....

So assuming you are using PST timezone currently on your server (PST is UTC minus 8Hr) 18:00 minus 8 should = 10:00 ?? So I think maybe you missing out the -t is allowing "at" to fall to the nearest hour from what I see in your posting .....

Though I'm not seeing why you think its backwards?

PST is winding the clock backwards from UTC by 8 hours.
NST is winding the clock backwards from UTC by 3 hours and 30 minutes

Again I have to say I'm no expert in "AT".

I would be more inclined to use cron and work out in advance the setting for the cron command timimngs

So assuming I have a PST time zone server and wanted the job to run at 23:30 GMT(UTC) then I would add the cron as

30 07 * * * /path/to/the/task/script

Or on a server with TZ = NST (NST = UTC - 3:30 hours)

00 02 * * * /path/to/the/task/script

I think !!!! ... I can see why you can get confused (I first also had it backwards and been through it 10 times ).


IHTH

Laurie.

 

[tarn]

Hmmm... Ok so while I was checking and checking and checking again over my last post I see more posts ...


So you think that cron is out of the question?

There should be no more effort in setting up a cron than setting an "AT" job really ...

Assuming that you are having to go to each of the (200-400) server then a little prep in advance locally with a file of predefined cron entries for each TZ and hostnames then you can just connect ssh (or whatever) and loop through the list to place the cron ... job done.

But you should be able to sort out the "AT" if that's going to be more familiar to you.

Good luck.

Laurie.

 

[stanhubble]

no the -t flag would force the time format to match the touch format [[CC]YY]MMDDhhmm[.ss]

my assumptions are that at 11:00 am GMT/UTC it is:

3:00 am in PST (-8) (not 18:00 which is +7)
6:00 am in EST (-5) (not 15:00 which is +4)
7:30 am in NST (-3.5) (not 13:30 which is +2.5)

which is why i think something is backward.

 

[tarn]

Like I say I'm not AT conversant but that's not how I read the -t flag

from

http://www.computerhope.com/unix/uat.htm

-t time Specifies at what time you want the command to be ran. Format hh:mm. am / pm indication can also follow the time otherwise a 24-hour clock is used. A timezone name of GMT, UCT or ZULU (case insensitive) can follow to specify that the time is in Coordinated Universal Time. Other timezones can be specified using the TZ environment variable. The below quick times can also be entered:

midnight - Indicates the time 12:00 am (00:00).
noon - Indicates the time 12:00 pm.
now - Indicates the current day and time. Invoking at - now will submit submit an at-job for potentially immediate execution.

Laurie .

 

[stanhubble]

Thanks the effort Laurie,

I don't know what version of linux/unix that site is catering to but it is not any of the posix compliant distros. (debian, redhat, suse)

all the systems i am trying to get this to run on are SLES, opensuse or sco openserver 5.

 

[stanhubble]

Again thanks for the help. I found a workaround, which is to force the timezone to gmt, schedule the at job, and restore the original timezone.

TMPTZ=$TZ;TZ=GMT
at 11:00 am < /usr/bin/startsrv
TZ=$TMPTZ

'at' serves a different purpose than cron. with 'at' you are able to schedule an event driven, non-recurring job for some time in the future.

 

[tarn]

Great workaround Stan, Yes I've seen that used before .... glad you have resolved your issue.

Laurie.

 

[Annihilannic]

A shorter equivalent which requires no temporary variables:

TZ=GMT at 11:00 am < /usr/bin/startsrv[/quote]

I have never heard of the "UTC" option you were trying nor could I see it documented on our systems (checked RHEL5 and HP-UX) so didn't comment earlier.

Annihilannic
[small][url=http://galaxy4.net/cgi-bin/tgmlify]tgmlify[/url] - code syntax highlighting for your tek-tips posts[/small]