Cron

http://www.csun.edu/helpdesk/linux.htm

The cron daemon is a truly nifty thing. Throughout the day (and night, if you leave your system running), it wakes up every minute, and checks /etc/crontab to see whether it needs to perform any tasks. If so, the utility executes them. It's as if you had a properly-trained robot typing commands at your keyboard. Cron is ideal for tasks that need to be carried out regularly—performing incremental backups is definitely one of them.

The cron daemon consults lots of system-level files, including several in /etc/cron, but each user can set up an individually tailored cron. To create your own cron, you'll need to use the crontab utility, which lets you create the crontab file and then installs this file correctly.

To create the crontab file, you need to type a command line. The syntax is simple. The first five fields of the line, separated by spaces, correspond to the following times:

If you type an asterisk in one of these fields, it means "all the times for this field." Following the five time fields is a command, just as if you'd type it at the keyboard. Here's an example: 15 * * * * echo "Hello, there"

This command tells cron to send the message "Hello, there," every fifteen minutes. Here's another example:

This command tells cron to execute the smbmount command every morning at 6:00 A.M. sharp.

To create a crontab file, log in using your ordinary user account, type cronttab -e, and press [Enter]. You'll see your default editor. Type the crontab commands you want to use, and exit the editor. Crontab will create your crontab file, and update your system so that the commands execute at the times you specified.

If you've learned the basics of the cron daemon and the crontab utility, you can use cron to schedule automatic incremental backups with the tar utility, as described in "Develop a backup routine" (Mar. 23, 2000). Here's the command to perform an automatic, incremental backup of an entire home directory (/home/bryan, in this example); note that this command is scheduled to run late every night, to be precise. (In case you've forgotten, cron commands begin with five time fields, corresponding to minute, hour, day of month, month, and day of week.)

The tar command updates the archive (backup.tar) with all the files that have been created or modified since the last incremental backup occurred.

You can also specify time ranges with cron. To specify a list of times, specify them in a comma-separated list:

This command removes core files from the specified directory at 3, 6, and 11 P.M. (the times are indicated using the 24-hour military clock).

To specify a range of times, use a hyphen. The following runs the specified tar command Monday through Friday, but gives tar a break on weekends:

To configure the user's cron settings, use crontab with the -e switch (crontab -e).

What's Vixie, you wonder? It's a nifty addition to the cron system, and it's installed by default with most Linux distributions (NB, default in RedHat and Debian). To find out whether you've got Vixie, take a look at your /etc directory; if you see directories such as /etc/cron.hourly, /etc/cron.daily, and so on, you've got Vixie.

And what does Vixie do? Essentially, Vixie is a scripting interface to cron. Vixie does its magic with a script called run-parts, which lives by default in the /usr/bin directory. This script looks for special commands in /etc/crontab, the system administrator's cron configuration file. These commands tell the run-parts script which directory to look in. At the specified time, the script examines this directory and executes all the scripts it finds.

Take a look in the /etc/crontab.* directories. Chances are you'll find lots of these scripts. If you add additional scripts to these directories, Vixie will execute them at the interval specified by the directory name (such as /etc/crontab.weekly) and the specific time given in /etc/crontab.

When you create a new user for your Linux system, most of the utilities used for this purpose (including Linuxconf and adduser) automatically create a new home directory for the user. What's more, these utilities also copy to the new home directory all the files that are found in /etc/skel. If you add files to those found in this directory, or change the files found in this directory, your additions and changes will automatically appear in every new user's directory. For example, suppose you'd like to give every user the benefit of a custom bash prompt you've devised. If you make the needed changes to the bash configuration files, every new user will see the customized bash prompt instead of the default. Note, however, that changes to /etc/skel don't affect existing directories; you'll have to change those manually.

In RH, cron jobs are not only in crotab, but also in /etc/cron.daily, etc.

In short, use /etc/cron.* or /etc/cron.d for systerm cron task. For personal cron jobs, use crontab still.

Verify the (- installed on …) line

http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/custom-guide/cron-task.html

The main configuration file for cron, /etc/crontab, contains the following lines:

The first four lines are variables used to configure the environment in which the cron tasks are run. The value of the SHELL variable tells the system which shell environment to use (in this example the bash shell), and the PATH variable defines the path used to execute commands. The output of the cron tasks are emailed to the username defined with the MAILTO variable. If the MAILTO variable is defined as an empty string (MAILTO=""), email will not be sent. The HOME variable can be used to set the home directory to use when executing commands or scripts.

Each line in the /etc/crontab file has the format:

minute hour day month dayofweek command

For any of the above values, an asterisk (*) can be used to specify all valid values, which always stands for “first-last”. For example, an asterisk for the month value means execute the command every month within the constraints of the other values.

A hyphen (-) between integers specifies a range of integers. For example, 1-4 means the integers 1, 2, 3, and 4.

A list of values separated by commas (,) specifies a list. For example, 3, 4, 6, 8 indicates those four specific integers.

The forward slash (/) can be used to specify step values. The value of an integer can be skipped within a range by following the range with /<integer>. For example, 0-59/2 can be used to define every other minute in the minute field. Step values can also be used with an asterisk. For instance, the value */3 can be used in the month field to run the task every third month.

Any lines that begin with a hash mark (#) are comments and are not processed.

As you can see from the /etc/crontab file, it uses the run-parts script to execute the scripts in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly files on an hourly, daily, weekly, or monthly basis respectively. The files in these directory should be shell scripts.

If a cron tasks needs to be executed on a schedule other than hourly, daily, weekly, or monthly, it can be added to the /etc/cron.d directory. All files in this directory use the same syntax as /etc/crontab, which are in a different format than those 'crontab -e' files.

The cron daemon checks the etc/crontab file, the etc/cron.d/ directory, and the /var/spool/cron directory every minute for any changes. If any changes are found, they are loaded into memory. Thus, the daemon does not need to be restarted if a crontab file is changed.

Users other than root can configure cron tasks by using the crontab utility. All user-defined crontabs are stored in the /var/spool/cron directory and are executed using the usernames of the users that created them. To create a crontab as a user, login as that user and type the command crontab -e to edit the user's crontab using the editor specified by the VISUAL or EDITOR environment variable. The file uses the same format as /etc/crontab. When the changes to the crontab are saved, the crontab is stored according to username and written to the file /var/spool/cron/username.

Blank lines and leading spaces and tabs are ignored. Lines whose first non-space character is a pound-sign (#) are comments, and are ignored. Note that comments are not allowed on the same line as cron commands, since they will be taken to be part of the command. Similarly, comments are not allowed on the same line as environment variable settings.

To start the cron service, use the command /sbin/service crond start. To stop the service, use the command /sbin/service crond stop. It is recommended that you start the service at boot time. Refer to Chapter 8 for details on starting the cron service automatically at boot time.

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.

The -e option is used to edit the current crontab using the editor specified by the VISUAL or EDITOR environment variables. After you exit from the editor, the modified crontab will be installed automatically.

cron(8) examines cron entries once every minute.

The time and date fields are:

A field may be an asterisk (*), which always stands for “first-last”.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. For example, 8-11 for an “hours” entry specifies execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Examples: “1,2,5,9”, “0-4,8-12”.

Step values can be used in conjunction with ranges. Following a range with “/<number>” specifies skips of the number's value through the range. For example, “0-23/2” can be used in the hours field to specify command execution every other hour (the alternative in the V7 standard is “0,2,4,6,8,10,12,14,16,18,20,22”). Steps are also permitted after an asterisk, so if you want to say “every two hours”, just use “*/2”.

From http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/custom-guide/cron-task.html

Here is an example showing how add an entry to etc/cron.d/ using symlinks.

create a file /path/to/sysbak.cron:

and in /path/to/sysbak.sh:

Then created a symlink:

That's it. Watch the syslog with

Then check the email.

Newsgroups: comp.os.linux.misc,comp.os.linux.admin,linux.redhat.misc Date: Tue, 25 Feb 2003 19:25:10 GMT

Support for crontabs under /etc/cron.d is flaky at best, often being undocumented and/or broken.

Robert Tinsley

Does crontab -e diddle the /etc/crontab file though? I always edit that one myself with emacs. I am not pushing emacs here: use whatever text editor you like. (I seldom need to edit /etc/crontab except when installing a new release or something.)

Jean-David Beyer

SuSE is using /etc/crontab too. I like it, if you have multiple cron jobs running as different app user, it's more pleasant (for me) to have them in a single file.

Michael Heiming

IIRC cron only mails when there is output.

Put '>/dev/null 2>&1' at the end of the command in your sf.net crontab.

Stefan O'Rear

You can disable all cron mail by setting 'MAILTO=""' in your crontab. See 'man 5 crontab' for details.

Patrick

http://thread.gmane.org/gmane.linux.debian.user/319121/focus=319134

Hi,

Please take a look at the following cron task:

It bewilders me that it is not doing what I want. Here is the syslog when it is run:

I.e., I want to execute a cron task if I'm not burning CD/DVD. But the actual command never get executed, even when I'm not burning CD/DVD. If I redo the command from the command line, it is fine:

So, what is the problem?

PS. I'm sure the PATH is setup properly in my cron, so cron can find ps & grep.

xpt

On Sun, 16 Mar 2008, NN_il_Confusionario wrote:

Thanks a lot. With your suggestion, I found the reason — it is as people (e.g. Raj) have suspected, it's problem of cron and quotes.

Here is the execute log:

The mail that I got says:

I.e., somehow, the 'ps | grep' was able to find something in cron, whereas when executed directly under shell:

I.e., if the same command are executed directly under shell the 'ps | grep' finds nothing.

Anyone can give some explanation?

xpt

On Tue, 18 Mar 2008, s. keeling wrote:

Nope, that didn't work. Thanks for the suggestion though s. keeling.

Here is what happened after I followed the above advice.

Now the crontab reads:

The mail that I got says:

when executed directly under shell:

I.e., having put the 'ps | grep' part into a shell script, the behavior is still the same.

xpt

On Tue, 18 Mar 2008, Bob McGowan <at> symantec.com wrote:

Exactly. Right on!

Bingo!!!

That's exactly the reason. As you can see from my script that I've already applied the '[]' trick, but the trick wasn't applied to all 3 grep cases. Having added '[]' to each of the grep cases, I finally see:

Bravo!!!

Thanks a lot to everyone who replied!

xpt

It always helps to read the documentation.

or

and, a really cool feature, for intervals other than one minute:

Paul Lutus

I have a .sh script that I run from the command line and also put into a cron job. I need to see the output on the screen and read a generated log file.

There are a couple of ways to approach this:

1) a file like: In this case the output goes to t.log but not on the screen

2) a file like: Using the tee command. But in this case I have to put

at every command I want to see, my real file is too long.

3) Final option. This uses the unix script command to output everything on the screen to the file t.log The script session must be terminated with a CTRL-D. The problem here is I don't know how to represent a ^D in a script. Can I execute it as an octal (004) but how?

Actually, no. Script terminates on EOF or when the child process terminates. ^D is just how *you* type EOF.

Imagine a script

Will this work? Of course not! "cat" doesn't read from the script - the script is being processed by /bin/ksh. "cat" reads from the script's input.

What you've just done is write a script to run script (with output to t.log)… But it runs script with no input specified, so it runs on stdin.

Try, perhaps

The last "exit" is because most shells terminate on exit.

Yes, this works.

documented on: 2000.05.23