Hi,
I am currently using the below at command, to schedule the script to run at a particular time,
at 2030 today <scriptname.ksh
I would like to know on how to run it every monday at around 11.30am (IST). Please help. Thanks in advance.
Hi,
I am currently using the below at command, to schedule the script to run at a particular time,
at 2030 today <scriptname.ksh
I would like to know on how to run it every monday at around 11.30am (IST). Please help. Thanks in advance.
Hi yohasini,
you can try to set a cron job with this options:
30 20 * * 2 Script.sh # every monday at 20:30
30 11 * * 2 Script.sh # every monday at 11:30
Regards.
I had tried the cron job..it doesn't work..so had to go in with at..do u have any info on how to do it with AT command?
You can try something like:
at '11 utc+ 30minutes' < Script.sh #To set the first run, assuming today is monday
or
at 1130 today < Script.sh#To set the first run, assuming today is monday
or
at 11:30am < Script.sh #To set the first run, assuming today is monday
And then go within the script and add at the end a line to invoke the Script.sh
itself to make a periodic task, something as follow:
at now + next week < Script.sh
or
at 1130 + 1 week < Script.sh
or
at 11:30am next week < Script.sh
Hope it helps.
Regards
at isn't meant for periodic scheduling, that's what cron is for. If it didn't work with cron, tell us the specific problem. Usually it's something along the lines of missing environment (cron doesn't read any of the profile scripts), missing path, incorrect assumptions about the working directory (cron will switch to a temporary path before executing your script).
The problem is i need to schedule a script to run on 16 servers and certain servers say that cron job doesn't exist,so we were asked to use at commands instead..
cron exists on (almost) all UNIX platforms, though a user may be excluded from using it. If that's the case (you'll get an appropriate error message when running crontab -e ), ask your SA to enable that user.
The problem with using at is, simply put, that you can't be sure if your script is causing a problem. With at, you'll have to re-insert the script into the execution queue everytime it finishes, successful or not. As soon as the script is ended forcefully, either by user intervention or a system failure it's out of the loop, and you'd be resposible to re-enter it, while cron does this automatically.
At my last company we used "at" for some periodic jobs. The script would re-at itself as it ran. We found that the script should re-at itself as the first thing it does in case it dies early. This was not a great solution, but it mostly worked. We did it because the user insisted that her job must run every 10 days... exactly. Running it on days 1, 11, 21 of the month (or anything like that) would not do. Exactly every 10 days. Using "at" seemed like the path of least resistance.
Depending on the cron version used it might even have been possible to use it, but yeah, this proves there's always an exception to a rule. However, for something so basic as "every monday" it simpler to use cron than at IMO.
Can you expand on this statement giving examples and real error messages?
Because "at" uses the "cron" daemon there is no sense in using "at" for a weekly job when a normal cron is designed for the task.
Don't forget to specify the full pathname to a script if you want to run it from cron.
There are two issues i have,
the at command, i am using is
at 0030 <$QDM_BIN_DIR/OBE_schedule.ksh
Please help me wiht this, i tried using "everyday" and "today" keywords along with at command but dint work too..
My solution would be to set your script as a start up application. Through the command date it can check the day, if Monday, let it run in a loop that checks every five minutes or so the time (through the command 'date' as well), if time is 11.30+-5 then break the loop and do whatever you want
I'd think this to be a very strange client requirement that you can use at, but not cron...
But as said before, it is possible to do with at, you just have to re-schedule the next run at the end of the current run.
@hakermania: That would only be effective if the system was restarted every day, or if the same user logs in every day.
Yes, I took for granted this fact
Hi yosasini,
Did you see/try the option I suggested on post #4?
Regards,
@yohasini
Strongly advise that you ask for proper privileges to use cron. This task is not suitable for recursive "at". Maybe try asking the client System Administrators for the contents of at.allow and cron.allow relevant to your user ... and then suggest changes.
As others posted there is no logic in allowing "at" but not allowing "cron".
Ps. The keywords available to "at" are specific to your Operating System. What Operating System do you have?
uname -a
This suggests that you actually have privileges to use cron. Please post full detail and error messages (or perhaps blank entries in the cron log) to justify "it doesn't work".
Is this you first time using cron?
There is no rational reason to use "at" for this task.
Ps. Error messages from failed cron logs will often be found in unix mail for the user who owns that crontab.