The other day I needed to have a job run daily. My two efforts at solving this problem failed. These were:

1. Ask the six people hanging around for no particular reason how to do it. All vaguely remembered learning that at some point and had forgotten specifically how to do it.

2. Using Google to see if I could find exactly how to do it in five minutes or less which was the amount of time I was willing to stick around after the end of an annoying day.

There are man pages but I have never been able to read a man page without wanting to find the people who wrote it and slap them.

crontab – maintain crontab files for individual users (ISC Cron V4.1)

crontab [-u user] file
crontab [-u user] [-l | -r | -e] [-i] [-s]

Crontab  is  the  program  used to install, deinstall or list the tables used to drive the cron(8) daemon in ISC Cron.  Each user can have their own crontab, and though these are files in /var/spool/ , they are  not  intended to  be  edited  directly.  For  SELinux  in  mls  mode  can be even more crontabs – for each range. For more see selinux(8).

If the cron.allow file exists, then you must be listed therein in order to be allowed to use this  command.   If the  cron.allow  file  does  not  exist  but  the  cron.deny file does exist, then you must not be listed in the cron.deny file in order to use this command.  If neither of these files exists, only  the  super  user  will  be allowed to use this command.

-u     It  specifies  the name of the user whose crontab is to be tweaked.  If this option is not given, crontab examines “your” crontab, i.e., the crontab of the person executing the command.  Note that su(8) can confuse crontab and that if you are running inside of su(8) you should always use the -u option for safety’s sake.  The first form of this command is used to install a new crontab from some named file  or  standard input if the pseudo-filename “-” is given.”

I mean, seriously, if that kind of thing is clear to you, you were raised by aliens. Joe, the sysadmin who was standing here five minutes ago disagrees. You know that means? It means Joe is wrong.

What a cron job is & how to see what cron jobs you have

A cron job is simply a job that runs at a certain time. A crontab is a table listing all the cron jobs.

To see the list of cron jobs in your account, log in and type

crontab -l

You should see something that looks like this:

00 08 * * *  /usr/joeblow/sas/default/bin/sas dir1/dir2/joesdayjob.sas
30 07 * * 1  /usr/joeblow/sas/default/bin/sas dir1/sub1/joesweekend.sas
31 07 1 * *  /usr/usc/sas/default/bin/sas dir2/sub1/monthlything.sas
20 08 * * * mail -s  ademars@usc.edu < dir1/dir2/things.txt

There are six fields in a cron job. The first one is minutes, the second is hours. Hours are on a 24-hour clock. The third field is day of the month, the fourth is month and the fifth is day of the week. Day of the week is 1= Monday through 7= Sunday. The last field is the command you want executed.

So, the first job above runs at 8 a.m. every day. It runs a job called joesdayjob.sas

The second job runs at 7:30 a.m. every Monday. It runs a job called joesweekend.sas

The third job runs at 7:31 a.m. on the first day of every month. It runs a job called monthlything.sas

The final job runs at 8:20 a.m. each day. It mails a file to me that is created at the end of the daily job just to tell me how frigging awesome I am. At the end of the daily job, SAS creates a file called things.txt . When everything is working it will send a message that says:

You are just unbelievably awesome.

If the job does not run successfully, I will get an error message and be sad, also, not awesome.

To change the recipient of the message, because, say, I go on vacation or get hit by a truck or something, a person could just change the email in the last line of the crontab.

How to edit your cron job

Please don’t do this unless you know what you are doing because if you delete the crontab, which is the table of cron jobs, and they all stop running, if some of them were my  jobs I would be most annoyed.

crontab -e

This will bring up the emacs editor. Add your job at the bottom. That way, if it has an error, the other jobs should run and only yours will be messed up, and so you have only caused trouble for yourself and not other people.

Save the file. That’s it.

Now, next time I google this I will find it.


Name (required)

Email (required)


Speak your mind

6 Comments so far

  1. paul on February 9, 2010 10:23 pm

    usually each person on a UNIX system has their own crontab, so unless you share the unix-level account with others, you probably dont have to worry about their edits messing your crontab

  2. admin on February 9, 2010 11:36 pm

    Well, each account has its own crontab. The particular account I was using is shared with a few other people. We use it both for some production jobs and for testing. Not the brightest combination, is it? There is a reason behind that but it isn’t a GOOD reason.

    Now that I think about it, I think I’ll talk to somebody about creating a separate testing account.

  3. Антон Павлович on March 19, 2010 11:20 am

    The other day I needed to have a job run daily. My two efforts at solving this problem failed. These were:

    Вы не правы. Я уверен. Могу отстоять свою позицию. Пишите мне в PM, пообщаемся….

  4. Paulette on February 3, 2011 3:03 pm

    thanks you made my day with this article and answered a burning question about using a .sas file!

  5. Clint on April 2, 2013 7:25 pm

    Your blog is one of the only ones I’ve come across that actually interests me. I feel inspired to knock the dust off of my STATA knowledge and brush up on statistics.

    Reading this old entry on cron jobs reminds me of the day I cursed a Debian linux server for not running a script I had in /etc/cron.hourly (a Debian-ish thing to make cron usage a little simpler). Fucking script just wouldn’t run. Specifically, it was a CLI PHP script to talk to an external web service and update some data on the server. As such, the file was named blahblah.php. I naively plunked the .php file in /cron.hourly, checked the permissions were good, and the fucker just wouldn’t run. Read the manpage on cron, no obvious mistakes being made on my part.

    After a solid half hour of googling, I realized it was the Debian “run-parts” program that enables the /etc/cron.hourly, /etc/cron.daily, etc. cronjob structure causing the problem.

    If any script within one of the cron directores has a “.” in the filename, which blahblah.php did, it will be skipped by cron.

    …. which has to be stupidest design decision I’ve ever run across in my life.

    So, if you ever happen to use Debian (or its derivatives Ubuntu, Mint, etc.) and utilize its run-parts cron directories, beware!

  6. Annmaria on April 2, 2013 10:05 pm

    Thanks for the compliment, Clint. I really appreciate your comments, too.


WP Themes