locate
command is updated daily. A system administrator can use automated tasks to perform periodic backups, monitor the system, run custom scripts, and more.
cron
, at
, and batch
.
cronie
RPM package must be installed and the crond
service must be running. anacron
is a sub-package of cronie
. To determine if these packages are installed, use the rpm -q cronie cronie-anacron
command.
systemctl is-active crond.service
root
:
systemctl start crond.service
root
:
systemctl stop crond.service
root
:
systemctl enable crond.service
/etc/anacrontab
(only root
is allowed to modify this file), which contains the following lines:
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=45 # the jobs will be started during the following hours only START_HOURS_RANGE=3-22 #period in days delay in minutes job-identifier command 1 5 cron.daily nice run-parts /etc/cron.daily 7 25 cron.weekly nice run-parts /etc/cron.weekly @monthly 45 cron.monthly nice run-parts /etc/cron.monthly
SHELL
variable tells the system which shell environment to use (in this example the bash shell). The PATH
variable defines the path used to execute commands. The output of the anacron jobs are emailed to the username defined with the MAILTO
variable. If the MAILTO
variable is not defined, (i.e. is empty, MAILTO=
), email is not sent.
RANDOM_DELAY
variable denotes the maximum number of minutes that will be added to the delay in minutes
variable which is specified for each job. The minimum delay value is set, by default, to 6 minutes. A RANDOM_DELAY
set to 12 would therefore add, randomly, between 6 and 12 minutes to the delay in minutes
for each job in that particular anacrontab. RANDOM_DELAY
can also be set to a value below 6, or even 0. When set to 0, no random delay is added. This proves to be useful when, for example, more computers that share one network connection need to download the same data every day. The START_HOURS_RANGE
variable defines an interval (in hours) when scheduled jobs can be run. In case this time interval is missed, for example, due to a power down, then scheduled jobs are not executed that day.
/etc/anacrontab
file represent scheduled jobs and have the following format:
period in days delay in minutes job-identifier command
period in days
— specifies the frequency of execution of a job in days. This variable can be represented by an integer or a macro (@daily
, @weekly
, @monthly
), where @daily
denotes the same value as the integer 1, @weekly
the same as 7, and @monthly
specifies that the job is run once a month, independent on the length of the month.
delay in minutes
— specifies the number of minutes anacron waits, if necessary, before executing a job. This variable is represented by an integer where 0 means no delay.
job-identifier
— specifies a unique name of a job which is used in the log files.
command
— specifies the command to execute. The command can either be a command such as ls /proc >> /tmp/proc
or a command to execute a custom script.
/etc/anacrontab
file:
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=30 # the jobs will be started during the following hours only START_HOURS_RANGE=16-20 #period in days delay in minutes job-identifier command 1 20 dailyjob nice run-parts /etc/cron.daily 7 25 weeklyjob /etc/weeklyjob.bash @monthly 45 monthlyjob ls /proc >> /tmp/proc
anacrontab
file are randomly delayed by 6-30 minutes and can be executed between 16:00 and 20:00. Thus, the first defined job will run anywhere between 16:26 and 16:50 every day. The command specified for this job will execute all present programs in the /etc/cron.daily
directory (using the run-parts
script which takes a directory as a command-line argument and sequentially executes every program within that directory). The second specified job will be executed once a week and will execute the weeklyjob.bash
script in the /etc
directory. The third job is executed once a month and runs a command to write the contents of the /proc
to the /tmp/proc
file (e.g. ls /proc >> /tmp/proc
).
cronie-anacron
package. Thus, you will be able to define jobs using crontabs only.
/etc/crontab
(only root
is allowed to modify this file), contains the following lines:
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user command to be executed
anacrontab
file, SHELL
, PATH
and MAILTO
. For more information about these variables, refer to Section 18.1.2, “Configuring Anacron Jobs”. The fourth line contains the HOME
variable. The HOME
variable can be used to set the home directory to use when executing commands or scripts.
/etc/crontab
file represent scheduled jobs and have the following format:
minute hour day month day of week user command
minute
— any integer from 0 to 59
hour
— any integer from 0 to 23
day
— any integer from 1 to 31 (must be a valid day if a month is specified)
month
— any integer from 1 to 12 (or the short name of the month such as jan or feb)
day of week
— any integer from 0 to 7, where 0 or 7 represents Sunday (or the short name of the week such as sun or mon)
user
— specifies the user under which the jobs are run
command
— the command to execute (the command can either be a command such as ls /proc >> /tmp/proc
or the command to execute a custom script)
1-4
means the integers 1, 2, 3, and 4.
3, 4, 6, 8
indicates those four specific integers.
/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.
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
. To list the contents of your own personal crontab file, use the crontab -l
command.
Do not specify a user
crontab
utility, there is no need to specify a user when defining a job.
/etc/cron.d/
directory contains files that have the same syntax as the /etc/crontab
file. Only root
is allowed to create and modify files in this directory.
Do not restart the daemon to apply the changes
/etc/anacrontab
file, 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 an anacrontab or a crontab file is changed.
/etc/cron.allow
and /etc/cron.deny
files are used to restrict access to cron. The format of both access control files is one username on each line. Whitespace is not permitted in either file. The cron daemon (crond
) does not have to be restarted if the access control files are modified. The access control files are checked each time a user tries to add or delete a cron job.
root
user can always use cron, regardless of the usernames listed in the access control files.
cron.allow
exists, only users listed in it are allowed to use cron, and the cron.deny
file is ignored.
cron.allow
does not exist, users listed in cron.deny
are not allowed to use cron.
/etc/security/access.conf
. For example, adding the following line in this file forbids creating crontabs for all users except the root
user:
-:ALL EXCEPT root :cron
access.conf.5
(i.e. man 5 access.conf
).
run-parts
script on a cron folder, such as /etc/cron.daily
, we can define which of the programs in this folder will not be executed by run-parts
.
jobs.deny
file in the folder that run-parts
will be executing from. For example, if we need to omit a particular program from /etc/cron.daily, then, a file /etc/cron.daily/jobs.deny
has to be created. In this file, specify the names of the omitted programs from the same directory. These will not be executed when a command, such as run-parts /etc/cron.daily
, is executed by a specific job.
jobs.allow
file.
jobs.deny
and jobs.allow
are the same as those of cron.deny
and cron.allow
described in section Section 18.1.4, “Controlling Access to Cron”.