Question

Up to now, we manage the crontabs of our servers by hand.

I have seen this:

http://django-extensions.readthedocs.org/en/latest/jobs_scheduling.html

It is a nice django app, since you just need to edit your crontab once.

You enter lines like this once, and for the future a software update is enough, no need to modify the crontab by hand to add new jobs.

@hourly /path/to/my/project/manage.py runjobs hourly

What I don't like about this: It needs django.

Has someone seen a solution which does not have such "big" dependencies?

For example a solution which uses EntryPoints to find all packages which have things to be done every hour/week/month?

Update

All cron jobs are installed per linux user, not as root.

Was it helpful?

Solution

The way with the least dependencies would be to simply utilize crontab and run-parts.

First, setup your user crontab to run a script for each schedule (e.g., crontab -e):

@hourly /path/to/run-hourly
@daily /path/to/run-daily
@weekly /path/to/run-weekly
@monthly /path/to/run-monthly

This would be similar to sym-linking each of those scripts to the respective /etc/cron.{hourly,daily,weekly,monthly} on Debian, but with the benefit of allowing the owning user to run them instead of root.

Second, define each script to run its jobs. For the simplest case, each script can use run-parts to run all executable job scripts within its specified directory.

#!/bin/bash
#/path/to/run-hourly
run-parts /path/to/hourly/jobs
#!/bin/bash
#/path/to/run-daily
run-parts /path/to/daily/jobs
#!/bin/bash
#/path/to/run-weekly
run-parts /path/to/weekly/jobs
#!/bin/bash
#/path/to/run-monthly
run-parts /path/to/monthly/jobs

Each script must also have execute permissions set:

chmod +x /path/to/run-{hourly,daily,weekly,monthly}

Third, sym-link any desired job to the respective job directory. E.g.,

chmod +x /path/to/job
ln -s /path/to/job /path/to/daily/jobs/

Alternatively, each schedule script could be defined to search for jobs in a common directory per project. Assuming each project is located under /path/to/projects and each project has descendant jobs/{hourly,daily,weekly,monthly}, then /path/to/run-hourly could be defined as:

#!/bin/bash
#/path/to/run-hourly
JOBS=$(find /path/to/projects -type f -path '*/jobs/hourly/*')
while read -r JOB; do
    "$JOB"
done <<< "$JOBS"

OTHER TIPS

This will depend on how your distribution configures cron, but you'll likely have an /etc/cron.d/ directory. This is a run-parts-style directory to hold cron configuration definitions.

Packages can drop a file there during installation to enable package-specific cron jobs.

For example, on my Ubuntu machine:

[jk@pecola ~]$ ls /etc/cron.d/
anacron  php5

[jk@pecola ~]$ cat /etc/cron.d/php5 
# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

The individual files are just a standard crontab(5) format.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top