Basic Linux task scheduling with cron

Sometimes you want to run commands nightly or weekly. You could just log in and run them yourself, but scheduling those tasks with cron is less hassle in the long run.


What is cron?

Behind the scenes, your VPS runs maintenance scripts on regular schedules. Some run nightly, some weekly, some might even run every five minutes. The scheduling for those tasks is done through a system called "cron". Most of the configuration for cron scheduling is done through files and directories that are fairly accessible.

If you want to run your own tasks on your VPS on regular schedules, you can use cron to do it. In this article we start off with the simplest approach, the cron directories.

Convenient directories

The most common schedules are pretty easy to use since they just involve picking the right directory. Over in /etc you should find several directories that start with the word "cron". The ones we want to look at right now are the ones that end with periods of time, like:

cron.daily
cron.hourly
cron.monthly
cron.weekly

The periods of time at the end of the names correspond to what they would describe in English. Any script put inside one of those directories will be run as often as the directory says it will. If a script is in "cron.weekly", for example, it will be run once a week.

You could put a symlink to a command inside a cron directory, but you usually want to pass at least some options to the command to be run, or may want to run a sequence of commands at one time (like piping the output of one command to another, or writing the output to a log). So most of the time the file you want to put into a cron directory is a script that runs your command or commands.

Basic scripting

Luckily that "script" thing I mentioned can be easier than it sounds too. We won't go into great depth about it here, but a basic shell script template looks like:

#!/bin/sh

first command
second command
third command
and so on

The first line describes the environment that will be used to run the script — the "shell". The "#!" tells the system you're describing the shell, and the rest of it is the command that runs the shell itself. You'll usually be fine just using "#!/bin/sh" like we did in the template.

The rest of the script is a list of the commands you want to run, as if you were typing them into the command line, one after the other.

If you wanted to run a couple custom programs, for example, your script could look like:

#!/bin/sh

/usr/local/bin/myprog --option andstuff
/opt/otherprog/bin/runthistoo >> stuff.log

This type of simple script is commonly called a "wrapper", since it wraps the commands you really want to run inside a script that can be easily called by other programs like cron. A wrapper can also be useful if you have a set of commands you commonly run together — just put them inside a wrapper, then you only need to type the name of the script to launch them all.

Script permissions

The final step when creating a script for cron to run is to tell the system the script is allowed to, well, be a script. To do that we need to give the script "execute permission".

Since cron runs as root, it's only really necessary to grant execute permission to "user" — the owner of the script. This can be done with the command:

chmod u+x scriptname

Replace "scriptname" with the name of your script, of course.

Summary

If you just need to use one of the basic scheduling intervals, then that's really all you need to know. It's as easy as putting the command you want to run inside a script, and putting that script into the appropriate cron scheduling directory.

You may need something more complex though, like running a script every half hour or having it run biweekly. For that we can move on to the next article in this series, which discusses more fine-grained task scheduling using the /etc/cron.d directory.

  • -- Jered

Article Comments:

Joel commented Tue Nov 16 19:47:56 UTC 2010:

I think the chmod script is a lowercase X for chmod u+x scriptname

Jered commented Wed Nov 17 23:09:33 UTC 2010:

Blast, you're right. The "X" only adds executable permission if it's already active for one of the permission groups. Fixing it, and thanks for pointing it out.

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)