Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
crontab scheduling
- Thread starter djessi
- Start date
- Thread starter
- #3
Let assume a cron that executes a backup every hour,
let suppose that for any reason the backup is not terminated and the cron executes another backup one
our later. I do not want the backup to be executed if
the former one is not terminated. What to do.
Thanks
let suppose that for any reason the backup is not terminated and the cron executes another backup one
our later. I do not want the backup to be executed if
the former one is not terminated. What to do.
Thanks
Here is where my ignorance is really gonna shine. I know just enough about cron to get by so there may be another way of doing this. I don't think you can do conditions directly with cron but you can definitely do it with scripts. Rather than having cron execute a shell command, maybe you can have it call a shell script. The script would simply create an empty file before the backup. When done the file is deleted. This way if the file exists, the script will not execute next time around. For this to work, your backup routine needs to exit with an error code or at least close the file so the script knows the the backup is complete.
I agree with RA;
cron is blind to any outcome of scheduled activities. it will LOG the information it knows about when a command is triggered and possibly how/when it ends. however, cron does not understand that your hourly job might take 75 minutes once it a while and therefore should behave in a particular manner.
I recommend that you have YOUR SCRIPT place a marker file (or some other artifact) that permits the script itself to figure out if it an instance of itself is still running before it tries again.
Conversely, you could make a daemon out of the script and let it schedule it's own launches based upon what it knows about itself.
I wouldn't plan to hold cron accountable for this kind of control.
D.E.R. Management - IT Project Management Consulting
cron is blind to any outcome of scheduled activities. it will LOG the information it knows about when a command is triggered and possibly how/when it ends. however, cron does not understand that your hourly job might take 75 minutes once it a while and therefore should behave in a particular manner.
I recommend that you have YOUR SCRIPT place a marker file (or some other artifact) that permits the script itself to figure out if it an instance of itself is still running before it tries again.
Conversely, you could make a daemon out of the script and let it schedule it's own launches based upon what it knows about itself.
I wouldn't plan to hold cron accountable for this kind of control.
D.E.R. Management - IT Project Management Consulting
anothermouse
IS-IT--Management
Best approach in this case is to use the same approach used for the majority of other daemons on the Linux system. You can examine the startup scripts (and source code of the executables) as numerous open source examples are available.
In simplistic terms, they create a file (as has already been suggested), but the additional trick is that the file contains the process ID if the script that has been started.
This means that when the script starts, it can first check whether the file exists, and then check whether the pid exists as well before making a decision as to what to do next. This enables daemon processes particularly to decide whether to quit, or whether to 'repair' or modify a running or hung instance of the script.
~~~~~~~~~~~~
A hacker has to be lucky once, the sysadmin has to be lucky always.
for remote IT support
~~~~~~~~~~~~
In simplistic terms, they create a file (as has already been suggested), but the additional trick is that the file contains the process ID if the script that has been started.
This means that when the script starts, it can first check whether the file exists, and then check whether the pid exists as well before making a decision as to what to do next. This enables daemon processes particularly to decide whether to quit, or whether to 'repair' or modify a running or hung instance of the script.
~~~~~~~~~~~~
A hacker has to be lucky once, the sysadmin has to be lucky always.
for remote IT support
~~~~~~~~~~~~
- Thread starter
- #7
- Status
Similar threads
- Locked
- Question