Maybe theres another solution to this. I built a web app that requires 5-10 crons to keep it maintained and various intervals. I want to check-in the crontab into version control, so that it can be easily deployed to other servers.
I would like to be able to put a line in the /etc/crontab file that would tell it to look into /myapp/app.crontab file and treat all the lines in that file as crontab entries... ie:
0 1 * * * root /bin/sh /do/something.sh
Why not just checkin /etc/crontab? Because when deploying from server to server, some servers may have different entries in their crontabs that i dont want to interfere with.
Any ideas?
What are other people doing for storing a bunch of crontab entries in rev ctrl?
Thanks.
Put your crontab file in /etc/cron.d/ - either as a checked out file or a symlink to the checked out file.
We take a very different approach to this problem on the project I'm working on.
We have a Perl script called crontab.pl that all servers call in their crontab. Doing it this way means the crontab never has to change on successive application deployments and the crontab.pl script can happily live in source control with the rest of the application source files.
We can specify different time intervals to this script with a command line parameter. The crontab looks like this:
*/5 * * * * /usr/local/apache/crontab.pl 5 > /var/log/crontab.log 2>&1 # 5 minute interval
1 * * * * /usr/local/apache/crontab.pl 60 > /var/log/crontab.log 2>&1 # 1 hour interval
1 1 * * * /usr/local/apache/crontab.pl 3600 > /var/log/crontab.log 2>&1 # 1 day interval
Then it is just a matter of reading in that command line time interval and running the tasks needed for the given interval.
Just add one (or very few) entries to crontab, and have that entry be a revision-controlled script that calls others:
0 * * * * /path/to/app/hourly.sh 0 0 * * * /path/to/app/daily.sh 0 1 * * 5 /path/to/app/weekly.sh
hourly.sh would then call everything that needs to be done hour, daily.sh would then call everything that needs to be done daily, etc.
I have found when managing large numbers of cron jobs for a single application that it is best not to have the jobs all hanging loose in the crontab, because that encourages you to overlook dependencies between them, i.e., one task that runs at 14 minutes past the hour depends on a task that runs at 12 minutes past the hour succeeding, but every so often that task takes 2.1 minutes to complete, and the other script fails, giving you a Heisenbug.
Another approach is to write your own daemon to manage these tasks.
The way I do this is put my crontab file in source control, and then in my deploy script, I replace the crontab file with what is being deployed.
You can do that like this:
crontab filename
Or for a specific user (must have superuser access for this):
crontab -u my_web_user filename
One big caveat with this is that it assumes there's only one crontab entry per user and that it's stored in SCM. If someone else edits the crontab on the server, those edits will be lost on the next deploy. So be aware of that.
来源：https://stackoverflow.com/questions/515341/how-to-delegate-within-a-crontab-to-use-another-file-as-a-crontab-aka-crontab-i