Winter 2016 - January to April 2016 - Updated 2018-10-29 18:50 EDT
There are two systems for running commands at later times and dates:
cron
system that runs command lines repeatedly according to a schedule, andat
system that runs a set of commands once, at a later time.cron
daemon and crontab
IndexUnix/Linux has a program named cron
that runs other programs at scheduled times, e.g. run a backup program every day at midnight. The cron
runs both system programs, reading the /etc/crontab
file, and personal cron
programs, created by a separate crontab
program.
A crontab
file is a table of lines, each of which is a time specification (24-hour clock) followed by a command line to execute at that time, e.g.
34 13 * * * touch /var/log/mark # touch at 1:34PM every day
Unix/Linux has both system (root
-only) crontab
files and personal user-level crontab
files. The date/time specifications are the same for both types of crontab
files. System crontab
files have an extra userid field after the date/time specification; it will be described below.
The cron
daemon examines and runs all crontab
entries no more than once every minute. (The cron
daemon can’t run anything more often than once a minute.)
If the system (or cron
daemon) isn’t up and running at a scheduled time, the command is ignored and is not run. The system doesn’t magically run missed cron
entries when the system is restarted. (There is a newer anacron
system that can do that.)
The cron
daemon is usually started as a service from a Run Level script when the system is booted, and it may not be configured to run in all Run Levels. The daemon produces log files that are usually kept under /var/log
; the actual location will be determined by your syslog
configuration settings.
crontab
time/date file formatIndexA crontab
is a text file of lines containing times and command lines. Each line starts with a five-field date/time specification. The five blank-separated time and date fields at the start of every crontab
line are (from man 5 crontab
):
crontab field allowed values
------------- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, if using a recent version of cron)
day of week 0-7 (0 or 7 is Sun, or use names)
Any field may be a list of numbers, separated by commas (no blanks allowed), or an asterisk (*
) indicating “every” or “all”, or a range of two numbers separated by a dash:
00,30 01,13 * * * touch /tmp/foo # touch every 30 minutes at 1am,1pm
00 08-11 * * * touch /tmp/foo # touch every hour from 8am to 11am
The minimum resolution of the crontab
is one minute, with some systems only running the crontab
every 15 minutes.
See more time/date examples below under “Personal crontab Examples”.
crontab
command line format and current directoryIndexThe command line in a crontab
file is any (non-interactive) shell command line. (Don’t try to run an interactive program such as the vim
text editor or a GUI program such as Firefox!)
The current working directory of the shell when it runs the personal crontab
command line is always your HOME
directory, so if you use pathnames in your command line make sure the pathnames are valid relative to your own HOME
directory:
* * * * * touch foo etc/bar # touch $HOME/foo and $HOME/etc/bar every minute
Lines that begin with #
are comments inside crontab
files. They are ignored.
crontab
filesIndexMost Unix/Linux systems now allow individual users to have private crontab
files for commands they want to run as themselves. Users must use the crontab
command to manage their personal cron
files. Changes take effect when the crontab
command saves your personal crontab
file and exits.
To edit your personal crontab
file, the crontab
command uses the text editor specified in the VISUAL
or EDITOR
environment variables:
$ crontab -l # show my personal crontab file
$ crontab -e # edit (or create) my crontab
$ crontab -r # delete my personal crontab
See man crontab
– the crontab
command for managing individual user crontab
files.
On Ubuntu desktop systems such as the CLS, your selected editor for crontab -e
is stored in the file ~/.selected_editor
and can be changed with the command select-editor
in many cases.
The current working directory of the shell when it runs the personal crontab
command line is always your HOME
directory, not the directory you were in when you ran the crontab
command.
crontab
ExamplesIndexBelow are some examples of personal crontab
entries:
* * * * * echo "every minute of every day of every month"
30 * * * * echo "30 minutes after every hour of every day of every month"
30 14 * * * echo "at 14:30 every day of every month"
30 14 15 * * echo "at 14:30 on day 15 of every month"
30 14 15 10 * echo "at 14:30 on day 15 of month 10 (October)"
30 14 * * 6 echo "at 14:30 every Saturday"
30 0,8,16 * * * echo "at 00:30, 08:30, and 16:30 every day of every month"
Below is an example (a very long line) that sends the current Ottawa temperature to a cell phone every hour. This requires the elinks
package and some form of mail
or mailx
package to be installed and configured to send Internet email. (To find your phone gateway, try http://www.notepage.net/smtp.htm.)
01 * * * * elinks -dump -no-numbering -no-references 'http://weather.gc.ca/rss/city/on-118_e.xml' | fgrep 'Temperature:' | mail -s "Temperature" 6135551212@msg.example.com
See man 5 crontab
– (manual section 5) the format of the crontab
files (personal and system).
The current working directory of the shell when it runs the personal crontab
command line is your HOME
directory.
-dump-charset latin1
or -dump-charset ascii
to the elinks
command line./etc/crontab
FileIndexThere is a system cron
configuration file /etc/crontab
that can run scheduled commands as any userid (usually as root
). You can (as root
) use a text editor to edit the system /etc/crontab
file. Changes take effect as soon as the file is saved.
Unlike personal crontab
files, the system crontab
command lines are prefixed by a userid field that tells which user to use to run the commands. The usual user is root
:
* * * * * root touch /var/log/file # run as root user
* * * * * syslog touch /var/adm/file # run as syslog user
* * * * * www-admin touch /var/http/file # run as www-admin user
The system crontab
file /etc/crontab
needs a userid field at the start of each command line to know as which user to run the cron
job. The personal crontab
file does not contain a leading userid field, since you can only run jobs as your own userid:
# example line from the system crontab file /etc/crontab (root userid):
17 * * * * root cd / && run-parts --report /etc/cron.hourly
# example line from a personal (non-root) crontab file (no userid):
34 12 * * * echo "It's 12:34 and time to eat lunch" | write idallen
The userid field in a system crontab
file comes after the time specification and before the text of the command line to run. It is only used in system crontab
files, never in personal crontab
files.
Unlike the system crontab
file /etc/crontab
, lines in personal crontab
files do not start with a leading userid field.
The current working directory of the shell when the cron
runs the system crontab
command line is the HOME
directory of the userid running the command. Most system crontab
lines run as the root
user.
/etc/cron.d
DirectoryIndexMany Unix/Linux systems also have a directory of individual system crontab
files under the /etc/cron.d/
directory.
Rather than editing and adding lines to the system /etc/crontab
, put those lines in a file and put the file under /etc/cron.d/
for automatic inclusion in the system crontab
.
Individual software packages can put their own files here without having to edit the main system crontab
file.
/etc/cron.{daily,hourly,weekly,monthly}
DirectoriesIndexMany Unix/Linux systems also have these directories:
/etc/cron.daily/
/etc/cron.hourly/
/etc/cron.weekly/
/etc/cron.monthly/
As the names indicate, programs or scripts placed in these directories will be executed (by the system crontab
) at at regular intervals, e.g. daily, hourly, weekly, or monthly.
at
command – run onceIndexIf you want to schedule some commands to happen just once at some time in the future, use the at
command.
The at
command is followed by a time or a time and a day or date. If you give both a date and a time, the date must follow the time (RTFM).
The program will prompt you for input. Enter the commands you want to run as standard input, one per line, then signal EOF:
$ date
Tue Nov 19 12:00:10 EST 2013
$ at 17:00
at> echo "Time to go home" | mail -s "Home Reminder" idallen
at> ^D
<EOT>
job 123 at Tue Nov 19 17:00:00 2013
$
$ at 12:00 friday
at> echo "lunch with Richard and Linus" | mail -s "Lunch Date" idallen
at> ^D
<EOT>
job 124 at Fri Nov 22 12:00:00 2013
$
$ at 00:01 jan 1
at> echo "Happy New Year" | mail -s "Auld Lang Syne" idallen
at> ^D
<EOT>
job 125 at Wed Jan 1 00:01:00 2014
$
The command accepts a wide range of time and date formats; see the man page for at
. Note that dates must follow times, as shown above.
The standard error and standard output from your commands, if any, will be sent to you by email when the job finishes. See below for how to read your email.
If the system (or at
daemon) isn’t up and running at the scheduled time that the at
job would run, the scheduled command will be saved and run as soon as the system starts. (Unlike cron
, which will not run missed events in the past.)
You can use the atq
command to display the list (“queue”) of pending jobs to be run. You can use at -c 123
to see the actual queued job commands for job 123
. (Since your entire environment is prefixed to each at
job, you might use the tail
command to see only the last few lines of the queued job.) You can cancel (“remove”) a scheduled job using atrm
:
$ atq
123 Wed Dec 5 12:00:00 2013 a idallen
$ at -c 123 | tail
[... see the last 10 lines of your queued job number 123 here ...]
$ atrm 123 # remove job 123
$ atq # show the queue of scheduled jobs
$
Since at
jobs run only once, there is no table of jobs similar to a crontab
. Use the atq
command.
Unlike personal crontab
jobs, which always have a current working directory of your HOME
directory when they run, the at
command jobs run using the current working directory in effect when the at
job was queued, so relative pathnames in at
jobs are relative to the same directory in which you created the at
job:
$ pwd
/tmp
$ at dec 1
at> touch foo # this will touch /tmp/foo not $HOME/foo
at> ^D
<EOT>
job 105 at Sun Dec 1 09:15:00 2013
cron
and at
jobsIndexSince both cron
and at
jobs run at times when you may not be logged in, any standard output and standard error output from the jobs is collected and sent to your account email inbox via EMail.
The Course Linux Server has a very basic EMail client installed for reading (and sending) text-only EMail messages.
You can read about it in the section EMail on the CLS in the Course Linux Server web page.