at, cron, and anacron
Scheduling Commands and Scripts
The at command and the related cron and anacron can help you efficiently schedule tasks, whether one-time events or jobs to be done repeatedly.
Scheduling tasks is as old as Unix. Usually, it is a concern for root users, handy for making sure that jobs like backups are done regularly. However, scheduling can also be useful for regular users, if only to broadcast a message to themselves to take a break. Either way, you have three scheduling systems for your needs: at
[1] and its related commands, cron
[2], and anacron
[3]. The three overlap, but each has its own peculiarities for configuration and scheduling.
The at Family of Commands
At
and its associated commands are for scheduling of a one-time event. By default, the commands can only be run by root. However, other users can also be permitted to run at
if you create a file called /etc/at.allow
, adding names one per line. You can also add users to /etc/at.deny
if there are users whom you specifically do not want to use the commands, including users that exist for administrative purposes or users that might be created by intruders, such as guest
(Figure 1).
To schedule a command to run once, enter the command followed by a time. The time must be precise down to minutes and can be precise down to seconds using the MMDDhhmm[.ss]
format. You can also specify the fixed times midnight
, noon
, or teatime
(4pm) or a specific date followed by the time. Similarly, you can specify now
, today
, or tomorrow
, optionally adding a time after now
or today
. For instance, 5pm + 1 week
or noon August 2
would both be valid time entries. Should you enter a time that has already passed, such as 11am today
when it is 4pm, the command will be run in about five minutes.
No matter how you enter the time, running the command will start the at
command prompt. Enter as many commands as you want at the prompt, and press Ctrl+D when you are finished (Figure 2). A message is sent to the user, who receives mail from root.
at
itself has a limited set of options. You can suppress mail with -m
or run a list of commands in a file using -f FILE
. There are also aliases for the related commands, but most users will probably find it easier to remember the full names of the commands. Here they are with examples:
atq
: Lists scheduled jobs. If used by root, everybody's jobs are listed (Figure 3).
atrm
: Removes scheduled jobs, using their job number. No confirmation dialog appears, so check job numbers usingatq
first.batch
: Used instead ofat
to run commands when the system load levels permit.Batch
accepts no time parameters, since they are irrelevant. Up to 52 batches can be set at one time. The names for batches begin with lowercase a, and end with uppercase Z.
Should you have trouble running the at
family of commands, run service atd status
. If at
is not running, you can start it with service atd start
.
Running cron Jobs
The main difference between at
and cron
is that at
is for a command to be scheduled once, and cron
is for a command to be used repeatedly. In addition, a cron
entry requires more information than an at
entry.
Like at
, the use of cron
is controlled by two files – in cron
's case, /etc/cron.deny
and /etc/cron.allow
. Both the cron
commands must be created using touch
before any user except root can use cron
. As with at
's files, cron
's files list users one per line. For added security, you may want to copy the contents of at.deny
into cron.deny
.
cron
jobs to be run are stored in a file called a crontab
. Non-root users can be given their own crontab
by running crontab -u USER FILE
, most likely using ~/.crontab.
To add a cron
job, run crontab -e
to manually enter a task. The first time a user runs crontab
, they are asked to select a default editor to use (Figure 4) from among those installed on the system. They can then enter a cron
job, one per line (Figure 5). Root's crontab
is commented, while other users' are not – presumably because non-root users are rare.
A cron
job has five fields:
MINUTES(0-59) HOURS(0-23) DAY-OF-THE-MONTH(1-31) MONTH(1-12) DAY-OF-THE-WEEK(0-6) COMMAND
Notice that the numbering is inconsistent: While days and months have the expected range of numbers, minutes, hours, days of the week begin at 0 instead of 1. There is no particular reason for this inconsistency except an outbreak of geekiness.
For example:
sends a message to all users about upcoming maintenance at 12:45 on Wednesday, May 13.
The first five fields do not have to be all filled out, so long as those that have an entry produce a legitimate date. For example, the day of the week, the fifth column could be left blank except for an asterisk so that the command would run on any May 13, no matter what the day of the week. In addition, each of the first five fields can be filled by a comma-separated list of entries. If you want to run a job at a regular interval, you can add an interval divided by 10 to the minutes field (for instance, */20
).
You can see a list of jobs by running cronjob -l
and remove the entire file with cronjob -r
.
All commands are written by default to /var/spool/cron/crontabs
, with separate entries or crontabs
for each authorized user. cron
also reads /etc/crontab
, /etc/cron.daily
, /etc/cron.weekly
, and /etc/cron.monthly
(which may have to be created). These directories consist simply of shell scripts that run 15 minutes after boot time or set in /etc/sysconfig/cron
file.
However, these entries in -etc
subdirectories are actually a redundancy, because the root user can get the same scheduling by selecting the fields to fill in the normal crontab
. It can be confusing to use two different forms of scheduling, and the trend in recent years is not to use them at all. Instead, users can replace the five traditional fields of a cron
job with the notations in Table 1.
Table 1
Descriptive Time Strings for Cron
String | Meaning |
---|---|
@reboot |
Run once at startup |
@yearly |
Run once a year, "0 0 1 1 *" |
@annually |
Run once a year, "0 0 1 1 *" |
@monthly |
Run once a month, "0 0 1 * *" |
@weekly |
Run once a week, "0 0 * * 0" |
@daily |
Run once a day,"0 0 * * *" |
@midnight |
Run once a day, "0 0 * * *" |
@hourly |
Run once an hour,"0 * * * *" |
Off and On with anacron
cron
was designed for systems that are always running, such as servers. By contrast, anacron
has the flexibility to run on machines that are frequently turned off and on, such as personal laptops and workstations. If a system is not turned on when an anacron
job is scheduled, it simply runs the next time the system is booted.
Another difference between cron
and anacron
is that anacron
's jobs are stored in the file/etc/anacronjob
. Jobs are added to anacronjob
using a text editor. One job is defined per line, in the following format:
PERIOD(DAYS) DELAY(MINUTES) ID COMMAND
PERIOD
is the number of days between each running of the command or else one of these tags: @daily
, @weekly
, or @monthly
. The period works with the DELAY
field, or the number of minutes after bootup that the job is run. Probably, you will want to run anacron
jobs at least ten minutes after bootup, just to assure that no other commands are run at the same time from login scripts. Otherwise, no more precise timing is available, and when a command runs is relative to the boot time, not an absolute time by the calendar and clock, as with cron
. The ID is the name of the command or script to run, the command, the actual path, and structure of the file. For instance,
runs the trim
command for SSD drives once a week 10 minutes after bootup.
You can view scheduled anacron
tasks with the command ls -l /var/spool/anacron/
(Figure 6). Tasks scheduled daily, weekly, or monthly will be marked.
anacron
is not set up with everyday users in mind. However, you can specify another anacrontab
using -t $~/etc/anacrontab
to specify a personal list of jobs, and -S $~/var/spool/anacron
for a personal spool in your ~/.profile
.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.