|
Home > Archive > Unix Shell > December 2007 > Daily scheduled job, but need to check if previous job has completed.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Daily scheduled job, but need to check if previous job has completed.
|
|
|
| I want to schedule cron to run a script each night, but should there
have been a lot of activity during the day, the script may take more
than a day to complete. So I need to check if the previous days job
has finished before starting today's. It doesn't matter if the script
doesn't run on the odd night here and there - I know that on average
the system will manage to keep up.
A friend has suggested to use a "touch" file but what if the system
crashes or some one reboots it - the touch file will still be present
and prevent the script from being run again. The friend also
suggested using a the process id for the script, but I am unsure how
to do this . . .
| |
| Joachim Schmitz 2007-11-30, 7:35 am |
| "Eliot" <ebp@hotmail.com> schrieb im Newsbeitrag
news:02316825-1df5-4510-8992-6459021ffa44@a39g2000pre.googlegroups.com...
>I want to schedule cron to run a script each night, but should there
> have been a lot of activity during the day, the script may take more
> than a day to complete. So I need to check if the previous days job
> has finished before starting today's. It doesn't matter if the script
> doesn't run on the odd night here and there - I know that on average
> the system will manage to keep up.
>
> A friend has suggested to use a "touch" file but what if the system
> crashes or some one reboots it - the touch file will still be present
> and prevent the script from being run again. The friend also
> suggested using a the process id for the script, but I am unsure how
> to do this . . .
Something along the lines of:
#!/bin/ksh
pidfile=/var/lock/pidfile-for-my-cronjob
if [ -f $pidfile ] && kill -0 $(cat $pidfile) 2>/dev/null
then
# pidfile exists and a process with that pid is running
# you may want to log this somehow
exit 1
fi
# record your pid
echo $$ >$pidfile
# your processing starts here
....
# and ends here
rm -f $pidfile
exit 0
Bye, Jojo
| |
| Rikishi 42 2007-12-01, 1:22 pm |
| On 2007-11-30, Eliot <ebp@hotmail.com> wrote:
> I want to schedule cron to run a script each night, but should there
> have been a lot of activity during the day, the script may take more
> than a day to complete. So I need to check if the previous days job
> has finished before starting today's. It doesn't matter if the script
> doesn't run on the odd night here and there - I know that on average
> the system will manage to keep up.
>
> A friend has suggested to use a "touch" file but what if the system
> crashes or some one reboots it - the touch file will still be present
> and prevent the script from being run again. The friend also
> suggested using a the process id for the script, but I am unsure how
> to do this . . .
The 'touched' marker file is a good and simple idea.
Should the system reboot because of a crash or a manual intervention, just
clean up the marker file at reboot. Cron can do this for you:
@reboot rm /MyPath/marker_file
Alternatively, you can also protect yourself from the situation where only
your task has crashed. Which would mean the machine isn't rebooting, but
the marker was left by the crashed task.
Just use find in a regular cron job, to clean the marker file if it's more
than x days old. If your task can take a day, but never 2, just use:
find -daystart -mtime +2 /MyPath/ -name "marker_file" -exec rm '{}' ';'
PS: If you task is a script, you could begin it with this cleanup.
--
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams
| |
| Joachim Schmitz 2007-12-06, 1:29 pm |
| "Eliot" <ebp@hotmail.com> schrieb im Newsbeitrag
news:556b4edd-0f4e-4e7f-aa78-9cd5f5dd314d@n20g2000hsh.googlegroups.com...
> Thanks for all the help!
>
> [The solution with] Kill -0 posted by Joachim Schmitz solved my
> problem, incidentally kill -0 wasn't in the man page or help on my
> box!
it may not be documented in kill(1), but should be in kill(2):
if the signal parameter has the value 0 (zero, the null signal), error
checking is performed but no signal is sent. The null signal can be used to
check the validity of the pid parameter
Bye, Jojo
| |
| Robert Latest 2007-12-06, 1:29 pm |
| Joachim Schmitz wrote:
> #!/bin/ksh
> pidfile=/var/lock/pidfile-for-my-cronjob
> if [ -f $pidfile ] && kill -0 $(cat $pidfile) 2>/dev/null
> then
> # pidfile exists and a process with that pid is running
> # you may want to log this somehow
> exit 1
> fi
> # record your pid
> echo $$ >$pidfile
> # your processing starts here
> ...
> # and ends here
> rm -f $pidfile
> exit 0
Nice! Saved for future reference. I didn't know about pid -0, I probably
would have done a grep on $(ps -a).
Grep and ps might actually be better because after the reboot there may be
some other process with the same pid, blocking a re-run of your script.
With ps you could check both invication name and pid of the program.
robert
| |
| Joachim Schmitz 2007-12-06, 1:29 pm |
| "Robert Latest" <boblatest@yahoo.com> schrieb im Newsbeitrag
news:5rqn3rF166fnuU1@mid.dfncis.de...
> Joachim Schmitz wrote:
>
>
> Nice! Saved for future reference. I didn't know about pid -0, I probably
> would have done a grep on $(ps -a).
signal 0 not pid 0. The latter exists too and has a different meaning.
> Grep and ps might actually be better because after the reboot there may be
> some other process with the same pid, blocking a re-run of your script.
That's why I mentioned "you may want to log this somehow".
> With ps you could check both invocation name and pid of the program.
ps -p $(cat pidfile)
might help here
Bye, Jojo
| |
| Robert Latest 2007-12-07, 1:29 pm |
| Joachim Schmitz wrote:
> signal 0 not pid 0. The latter exists too and has a different meaning.
Sorry, of course I meant kill -0.
robert
|
|
|
|
|