General:
http://www.attrition.org/security/newbie/unix/cron-1.html

debian..: /var/spool/cron/crontabs,/etc/:cron.d,crontabs,cron.{daily|hourly|monthly|weekly}
openbsd.: /var/cron
openwrt.: /var/spool/cron/crontabs

debian:
	usage:  crontab [-u user] file
	        crontab [-u user] { -e | -l | -r }
	                (default operation is replace, per 1003.2)
	        -e      (edit user's crontab)
	        -l      (list user's crontab)
	        -r      (delete user's crontab)

openwrt:
	To re-load crond with new settings:
		killall crond; /etc/init.d/S60cron

	BusyBox v1.00 (2005.11.23-21:46+0000) multi-call binary
	Usage: crontab [-c dir] {file|-}|[-u|-l|-e|-d user]
	        file   replace crontab from file
	        -      replace crontab from stdin
	        -u user      specify user
	        -l [user]    list crontab for user
	        -e [user]    edit crontab for user
	        -d [user]    delete crontab for user
	        -c dir       specify crontab directory

	BusyBox v1.00 (2005.11.23-21:46+0000) multi-call binary
	Usage: crond -d[#] -c  -f -b
	        -d [#] -l [#] -S -L logfile -f -b -c dir
	        -d num  debug level
	        -l num  log level (8 - default)
	        -S      log to syslogd (default)
	        -L file log to file
	        -f      run in fordeground
	        -b      run in background (default)
	        -c dir  working dir

Note that /var/spool/cron/crontabs/ is the default directory that crond will
check for configuration. However, anything in /var/ is lost during a reboot,
so we'll use another directory to ensure our crontab file persists between
reboots.

Logging by crond 
Note that by default, crond will log a message to the syslog every time it
executes a scheduled job. The easiest way to stop these from being logged
is to configure crond to send all log messages to /dev/null. To do so,
edit /etc/init.d/S55crond and change it to:
	/usr/sbin/crond -c /etc/crontabs -L /dev/null
After restarting crond, it will no longer send any log messages to the syslog.
Note that this also means that crond will not log any errors to syslog, so be
sure to confirm that crond is operating correctly before configuring it to use
/dev/null for logging.

The command portion of the line is run with /bin/sh -c  and may
therefore contain any valid bourne shell command. A common practice is to run
your command  with exec to keep the process table uncluttered. It is also
common to redirect output to a log file.

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.

Several environment variables are set up automatically by the cron(8) daemon.
SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd
line of the crontab's owner. HOME and SHELL may be overridden by settings in
the crontab; LOGNAME may not.

Another note: the LOGNAME variable is sometimes called USER on BSD systems...
on these systems, USER will be set also.

In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has
any reason to send mail as a result of running commands in ``this'' crontab.
If MAILTO is defined (and non-empty), mail is sent to the user so named. If
MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail
is sent to the owner of the crontab. This option is useful if you decide on
/bin/mail instead of /usr/lib/sendmail as your mailer when you install cron --
/bin/mail doesn't do aliasing, and UUCP usually doesn't read its mail.

--------------------------------------------------------------------------------

Schedule and Command Notes

A field may be an asterisk (*), which indicates all values in the range are
acceptable. Ranges of numbers are allowed, i.e. "2-5" or "8-11", and lists of
numbers are allowed, i.e. "1,3,5" or "1,3,8-11". Step values can be represented
as a sequence, i.e. "0-59/15", "1-31/3", or "*/2".

Ranges are specified with a hyphen, for example: 9-17, treats for any value
between 9 and 17. So if placed in day of month this would be days 9 through 17.
Or if put in hours it would be between 9 and 5.

Step values can be used in conjunction with ranges. Following a range with
"/" 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".

Names can also be used for the "month" and "day of week" fields. Use the first
three letters of the particular day or month (case doesn't matter). Ranges or
lists of names are not allowed.

The "sixth" field (the rest of the line) specifies the command to be run. The
entire command portion of the line, up to a newline or % character, will be
executed by /bin/sh or by the shell specified in the SHELL variable of the
cronfile. Percent-signs (%) in the command, unless escaped with backslash (\),
will be changed into newline characters, and all data after the first % will
be sent to the command as standard input.

Note: The day of a command's execution can be specified by two fields: day of
month, and day of week. If both fields are restricted (ie, aren't *), the
command will be run when either field matches the current time. For example,
"30 4 1,15 * 5" would cause a command to be run at 4:30 am on the 1st and 15th
of each month, plus every Friday.

When specifying day of week, both day 0 and day 7 will be considered Sunday.
BSD and ATT seem to disagree about this.

Lists and ranges are allowed to co-exist in the same field. "1-3,7-9" would be
rejected by ATT or BSD cron -- they want to see "1-3" or "7,8,9" ONLY.

Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9". 

Names of months or days of the week can be specified by name. 

Environment variables can be set in the crontab. In BSD or ATT, the environment
handed to child processes is basically the one from /etc/rc.

These special time specification "nicknames" are supported, which replace the
5 initial time and date fields, and are prefixed by the '@' character:

	@reboot    :    Run once, at startup.
	@yearly    :    Run once a year, ie.  "0 0 1 1 *".
	@annually  :    Run once a year, ie.  "0 0 1 1 *".
	@monthly   :    Run once a month, ie. "0 0 1 * *".
	@weekly    :    Run once a week, ie.  "0 0 * * 0".
	@daily     :    Run once a day, ie.   "0 0 * * *".
	@hourly    :    Run once an hour, ie. "0 * * * *".

--------------------------------------------------------------------------------

reboot router each night at 3am

router:/etc/cron.d/check_ps:
	*/2 * * * * root /sbin/check_ps
bluebox:/etc/crontabs/root:
	0 * * * *  rdate time.nist.gov
S60cron:
[ -d /etc/crontabs ] && crond -c /etc/crontabs

# reboot.job:
# 00m  00h  00dm  00m  0dw  cmd
  00   03   *     *    *    /sbin/reboot


# openwrt:/etc/crontabs/root:
# 00m  00h  00dm  00m  0dw  cmd
  00   03   *     *    *    /sbin/reboot
  00   *    *     *    *    /usr/sbin/rdate time.nist.gov
  */1  *    *     *    *    /bin/date >>/tmp/cronx.txt

/etc/init.d/S60cron:
#!/bin/sh
[ -d /etc/crontabs/ ] || mkdir -p /etc/crontabs
[ -d /var/spool/cron/crontabs/ ] || {
        mkdir -p /var/spool/cron
        ln -s /etc/crontabs /var/spool/cron/crontabs
}
[ -d /etc/crontabs ] && crond -c /etc/crontabs


--------------------------------------------------------------------------------

# /etc/crontab/root:
#
# use /bin/sh to run commands, no matter what /etc/passwd says
# SHELL=/bin/sh
# mail any output to `paul', no matter whose crontab this is
# MAILTO=root
#
# minute   hour   day of month   month   day of week   command
# *        *      *              *       *             echo hello world!
#
#	minute of the hour
#	hour of the day (on the 24 hour clock)
#	day of the month
#	month of the year (1 = January, 2 = February, etc.)
#	day of the week (0 = Sun, 1 = Mon, 2 = Tue, ..., 6 = Sat)
#
# Cron jobs are a way of automating tasks that you want done every
# week/month/day and at a certain time.
#
# A "*" in one of these fields indicates that the job should be executed at any
# or every one of these, so for instance a "*" in the month of the year field
# means that this task should be carried out every month at the time specified
# in the other fields. A "*" in the day of the week field, when there is
# something in the day of the month field, does not mean that this task should
# be carried out every day, but rather that it should be carried out on the
# appointed day of the month regardless of what weekday it is. Only "*"s in the
# day of the week field, and the day of the month field, and the month of the
# year field would indicate a daily task.
#
# Examples:
#   skeleton.job:
#     00m  00h  00dm  00m  0dw  cmd
#     00   00   *     *    *    command
#   This job runs every five minutes:
#     */5 * * * *
#     The special */5 in the first line, means that this job is executed
#     every 5 mins. At the minutes 5, 10, 15.....55.
#   The job with this time to run would run every Sunday at 12:20 am:
#     20 00 *  * 0
#   This job would run at midnight on any Friday the 13th:
#     00 00 13 * 5
#   You don't have to put just one time in a field. This job, for instance,
#   would run every day at 12:30am, 2:30am, 4:30am, 6:30am, 6:30pm, 8:30pm,
#   and 10:30pm:
#     30 0,2,4,6,18,20,22 * * *
#   This one would run every Tuesday and Friday at 5:30 am:
#     30 5 * * 2,5
#   This one would run every night at 12 am:
#     00 0 * * * /fullpathto/cgi-bin/program.cgi 
#
# Notify cron daemon of a new cron job:
#   Create a cron.job in a directory and then type:
#     crontab cron.job
#   To verify the cron job registered type:
#     crontab -l
#
#
#
#
# Execute the "vnukelog" command every 10 minutes for for the first
# half-hour (0-30/10) of the 9:00 AM and 5:00 PM hours (9,17) on
# Monday-Friday (1-5).
# 0-30/10 9,17 * * 1-5  /usr/local/bin/vnukelog
#
# Execute the "vnukelog" command at 4:00 AM, 8:00 AM, 12:00 noon, 4:00 PM,
# and 8:00 PM (0 */4) on each Sunday (sun) every January (jan).
# 0 */4 * jan sun  /usr/local/bin/vnukelog
#
# Execute the "vnukelog" command at 4:30 AM (30 4) on the first, fifteenth
# (1,15), and each Friday (fri) of every month.
# 30 4 1,15 * fri  /usr/local/bin/vnukelog
#
# Execute the "vnukelog" command at 12:00 midnight (0 0) on August 19 (8) (aug)  
# 0 0 19 8   *  /usr/local/bin/vnukelog
# 0 0 19 aug *  /usr/local/bin/vnukelog
#
# Reboot Schedule:
# 00  05  *   *   1-5 /sbin/reboot
# 1 = Monday 5am - 5 = Friday 5am
# skipping: 6: SAT morning (FRI night) / 0|7: SUN morning (SAT night)
#
# Create Debian Style Cron Scripts (debian uses folders)
# 00  *   *   *   *   ${BASE}/etc/cron/cron.hourly.sh
# 00  00  *   *   *   ${BASE}/etc/cron/cron.daily.sh
# 00  00  *   *   00  ${BASE}/etc/cron/cron.weekly.sh
# 00  00  01  *   *   ${BASE}/etc/cron/cron.monthly.sh
#
--------------------------------------------------------------------------------

This pings two servers, one each even hour and the other each odd hour:

0 0,2,4,6,8,10,12,14,16,18,20,22 * * * ping -c 3 server1.com >/dev/null 2>&1
0 1,3,5,7,9,11,13,15,17,19,21,23 * * * ping -c 3 server2.com >/dev/null 2>&1

Automatically generate a file which would consist of a list of all files
and subdirectories under a certain directory.

0 0,6,12,18 * * * ls -lhABGR /mnt/data/upload/ > /mnt/data/upload/index.txt

Periodically mirroring a directory
Here I'm using lftp to upload the files to another server (reverse mirroring).
Here is what I inserted in my crontab:

0 23 * * wed,sun lftp -e 'open www.mysecondserver.com -u username,password -p 21 && mirror --continue --reverse --delete /my/local/directory /my/remote/directory' >/dev/null 2>&1

I decided that backing up twice per week (Wednesday and Sunday) would be
sufficient, since I did not have any mission critical data stored in this
directory. Combined with the tip above, you could save some space. See the
lftp manual page for more info. You would probably want to use rsync if
there are larger amounts of data in question.

--------------------------------------------------------------------------------

25 0 1 * *    /usr/forum/bin/monthly-diary-rotate.csh

How can we tell that's what it does?

An entry consists of two parts-- a time to run, and a command to run.
(The top line beginning with a # mark is a comment, and is only there
to remind people reading the file what the entry is there for.) The
time to run (the first part of the entry) is broken up into 5 fields:

	minute of the hour
	hour of the day (on the 24 hour clock)
	day of the month
	month of the year (1 = January, 2 = February, etc.)
	day of the week (0 = Sunday, 1 = Monday, 2 = Tuesday, ..., 6 = Saturday)

A "*" in one of these fields indicates that the job should be executed at any
or every one of these, so for instance a "*" in the month of the year field
means that this task should be carried out every month at the time specified
in the other fields. A "*" in the day of the week field, when there is
something in the day of the month field, does not mean that this task should
be carried out every day, but rather that it should be carried out on the
appointed day of the month regardless of what weekday it is. Only "*"s in the
day of the week field, and the day of the month field, and the month of the
year field would indicate a daily task.

Examples: The job with this time to run would run every Sunday at 12:20 am.
	20 0 * * 0

This job would run at midnight on any Friday the 13th.
	0 0 13 * 5

You don't have to put just one time in a field. This job, for instance, would
run every day at 12:30am, 2:30am, 4:30am, 6:30am, 6:30pm, 8:30pm, and 10:30pm:
	30 0,2,4,6,18,20,22 * * *

and this one would run every Tuesday and Friday at 5:30 am:
	30 5 * * 2,5

Creating a new Crontab

create a new file named work.run
all other crontabs you are running should also be placed in this file. 
in this file you will put the following line
	00 0 * * * /fullpathto/cgi-bin/program.cgi 

This will run program.cgi everynight at 12 am ........
Change the 00 and * to whenever you want the script to be updated according to
what info is above....

Now upload this file (work.run) to your server
Telnet into your account and go to the dir you uploaded work.run into Type:
	crontab work.run

This should set your cron job, to make sure type crontab -l

--------------------------------------------------------------------------------