Overview
In this tutorial, learn to:
- Use the
cron
andanacron
commands to run jobs at regular intervals - Use the
at
command to run jobs at a specific time - Manage
cron
andat
jobs - Configure user access to the
cron
andat
services
Scheduling jobs
Many system administration tasks must be done regularly, such as rotating log files, backing up files or databases, preparing reports, or installing system updates. If you automate these tasks, they can run without manual intervention and when other system use is low. By setting up routine jobs for automatic scheduling, you also ensure that they always run the same way.
You also might need to run an individual job at a time when you do not plan to be at work or otherwise connected to your computer. In this tutorial, I show you how to automate periodic job scheduling and how to schedule a single job to run at a specific time. I also show you how to query and manage scheduled jobs.
This tutorial helps you prepare for Objective 107.2 in Topic 107 of the Linux Server Professional (LPIC-1) exam 102. The objective has a weight of 4.
Prerequisites
To get the most from the tutorials in this series, you need a basic knowledge of Linux and a working Linux system on which you can practice the commands covered in this tutorial. You should be familiar with GNU and UNIX commands. Sometimes different versions of a program format output differently, so your results might not always look exactly like the listings shown here.
Unless otherwise noted, I use Mint 17 (Rosa) for the examples in this tutorial.
Run jobs at regular intervals
Linux systems have two facilities for scheduling jobs to run at regular intervals:
- The original
cron
facility is best suited to servers and systems that are continuously powered on. - The
anacron
(or anachronisticcron
) facility is suited to systems such as desktops or laptops that can be asleep or running on battery power.
summarizes some of the major differences between the two facilities.
Table 1. Comparing cron and ana cron
cron | anacron |
---|---|
Good for servers | Good for laptops and desktops |
Granularity from one minute to one year | Daily, weekly, and monthly granularity |
Job runs only if system is running at scheduled time | Job runs when system is next available |
Can be used by normal users | Needs root authority |
I discuss cron
next, and anacron
in the “Schedule periodic jobs with anacron
” section.
Schedule periodic jobs with cron
The cron
facility consists of the cron
daemon and a set of tables that describe what work is to be done and with what frequency. The cron
daemon is usually started by the init
, upstart
, or systemd
process at system startup. The cron
tables are called crontabs. The cron
daemon wakes up every minute and checks each crontab for jobs that need to run. Users manage crontabs by using the crontab
command.
Note: Some systems refer to the cron
daemon as crond
. For this tutorial, I use cron
.
For a simple example, suppose that you want to test the cron
facility by running a command to display the day and date on a regular basis. shows a simple script for this purpose and the output that you might see if you run the script.
Listing 1. A simple cron example
ian@attic‑mint17 ~ $ cat mycrontest.sh
#!/bin/bash
echo "Running $0. It is now $(date +%T) on $(date +%A)"
ian@attic‑mint17 ~ $ ./mycrontest.sh
Running ./mycrontest.sh. It is now 22:07:09 on Friday
The mycrontest.sh script in Listing 1 reports the name of the script, the day, and the time, and you know when the script runs by viewing the output.
Note: When you create crontab entries, be careful with quoting or escaping, so that the shell does not interpret your commands in ways you do not want. Often, it is easier to create a small script as I did with mycrontest.sh, rather than try to escape complex parameter strings correctly. A few simple parameters are easier to work with than many complex strings that have to be escaped.
Creating a crontab
Use the crontab
command with the -e
(for edit) option to create a crontab. By default, crontab
opens the vi
editor so you can enter commands. If you have another editor in the EDITOR
or VISUAL
environment variable, crontab
opens that editor instead of vi
. On some systems, such as my Mint system, you can also choose the editor from a list when you run crontab
for the first time, as shown in Listing 2.
Listing 2. Editing with crontab on Linux Mint
ian@attic‑mint17 ~ $ crontab ‑e
no crontab for ian ‑ using an empty one
Select an editor. To change later, run 'select‑editor'.
1. /bin/ed
2. /bin/nano <‑‑‑‑ easiest
3. /usr/bin/emacs24
4. /usr/bin/vim.tiny
Choose 1‑4 [2]:
Each crontab entry contains this sequence of six blank-separated fields:
- Minute
- Hour
- Day of the month
- Month of the year
- Day of the week
- String to be executed by
sh
Minutes range from 0
to 59
, hours from 0
to 23
, days from 1
to 31
, and months from 1
to 12
. Day of week ranges from 0
to 7
, with 0
or 7
being Sunday. You can also specify day of week as sun
, mon
, tue
, and so on. The sixth field — everything after the fifth field — is interpreted as a string to pass to sh
. A percent sign (%
) is translated to a newline, so if you want a %
or any other special character, precede it with a backslash (\
). The line up to the first %
is passed to the shell, whereas any lines after the %
are passed as standard input. The time-related fields can specify an individual value, a range of values such as 0-10
or sun-wed
, or a comma-separated list of individual values and ranges. A value of *
means the entire range.
Here is a somewhat artificial crontab entry for my example mycrontest.sh
command:
0,20,40 6‑10,21‑23 ∗ 3 thu‑sat /home/ian/mycrontest.sh
In this example, mycrontest.sh
is executed at the 0th, 20th, and 40th minutes (every 20 minutes), for the hours between 6 a.m. and 10 a.m. and again between 9 p.m. and midnight on Thursdays, Fridays, and Saturdays during March. Run man 5 crontabman5crontab
to see details on additional ways to specify times.
You can also use the special nicknames shown in Table 2, which start with @
, for time specifications.
Table 2. Nicknames for cron time specifications
Nickname | Run when | Equivalent to |
---|---|---|
@reboot | Run once after reboot | |
@hourly | Run once an hour | 0 |
@daily | Run once a day | 0 0 |
@monthly | Run once a month | 0 0 1 |
@yearly | Run once a year | 0 0 1 1 |
@annually | Run once a year | 0 0 1 1 * |
After you save your edited crontab, the crontab
command installs your new crontab so that the system knows about your jobs. You can use crontab
to install a prepared crontab file if you created it with another editor. See the man pages for crontab
.
What about the output?
You might be wondering what happens to any output from the command. Most commands designed for use with the cron
facility log output by using the syslog
facility. Any output that is directed to stdout is mailed to the user. Listing 3 shows output from the mycrontest.sh
command.
Listing 3. Mailed cron output
Return‑Path: <ian@attic‑mint17>
X‑Original‑To: ian
Delivered‑To: ian@attic‑mint17
Received: by attic‑mint17 (Postfix, from userid 1000)
id CF1651214A8; Fri, 4 Mar 2016 23:20:01 ‑0500 (EST)
From: root@attic‑mint17 (Cron Daemon)
To: ian@attic‑mint17
Subject: Cron <ian@attic‑mint17> /home/ian/mycrontest.sh
Content‑Type: text/plain; charset=ANSI_X3.4‑1968
X‑Cron‑Env: <SHELL=/bin/sh>
X‑Cron‑Env: <HOME=/home/ian>
X‑Cron‑Env: <PATH=/usr/bin:/bin>
X‑Cron‑Env: <LOGNAME=ian>
Message‑Id: <20160305042001.CF1651214A8@attic‑mint17>
Date: Fri, 4 Mar 2016 23:20:01 ‑0500 (EST)
Status: O
X‑UID: 14
Running /home/ian/mycrontest.sh. It is now 23:20:01 on Friday
Notice that the mailed output includes lines such as X-Cron-Env:<SHELL=/bin/sh>
. You can set environment variables in your crontab to control the PATH
that’s used when your command is executed, or the user to whom mail will be sent. See the System crontabs in /etc section or the man page for crontab
for more information.
Where is my crontab?
The crontab that you create with the crontab
command is stored in a subdirectory of /var/spool/cron under the name of the user who created it. The specific location can vary by system. On my Mint system, my crontab is stored in /var/spool/cron/crontabs/ian, whereas on my openSUSE 42 system it is stored in /var/spool/cron/tabs/ian. The crontabs are stored in a system directory, so you will not be surprised to learn that the crontab
command is an suid
program that runs with root authority, like a few other commands such as passwd
. Typical permissions on a crontab restrict you to accessing it only by using the crontab
command. Listing 4 shows the file and directory permissions and the contents of my crontab on both the Mint and openSUSE systems.
Listing 4. File and directory permissions for my crontab
attic4‑s42:~ ##openSUSE
attic4‑s42:~ #ls ‑l /var/spool/cron/
total 8
drwxr‑xr‑x 2 root root 4096 Mar 4 07:30 lastrun
drwx‑‑‑‑‑‑ 2 root root 4096 Mar 4 07:07 tabs
attic4‑s42:~ #ls ‑l /var/spool/cron/tabs
total 4
‑rw‑‑‑‑‑‑‑ 1 ian users 197 Mar 4 07:07 ian
attic4‑s42:~ #cat /var/spool/cron/tabs/ian
#DO NOT EDIT THIS FILE ‑ edit the master and reinstall.
#(/tmp/crontab.kUd79z installed on Fri Mar 4 07:07:06 2016)
#(Cronie version 4.2)
0,20,40 6‑10,21‑23 ∗ 3 thu‑sat /home/ian/mycrontest.sh
ian@attic‑mint17 ~ $ #Mint 17
ian@attic‑mint17 ~ $ sudo ls ‑l /var/spool/cron
total 12
drwxrwx‑‑T 2 daemon daemon 4096 Feb 29 18:38 atjobs
drwxrwx‑‑T 2 daemon daemon 4096 Oct 21 2013 atspool
drwx‑wx‑‑T 2 root crontab 4096 Mar 4 08:38 crontabs
ian@attic‑mint17 ~ $ sudo ls ‑l /var/spool/cron/crontabs/
total 4
‑rw‑‑‑‑‑‑‑ 1 ian crontab 1145 Mar 4 08:38 ian
ian@attic‑mint17 ~ $ sudo cat /var/spool/cron/crontabs/ian
#DO NOT EDIT THIS FILE ‑ edit the master and reinstall.
#(/tmp/crontab.3RmM35/crontab installed on Fri Mar 4 08:38:24 2016)
#(Cron version ‑‑ $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#Edit this file to introduce tasks to be run by cron.
#
#Each task to run has to be defined through a single line
#indicating with different fields when the task will be run
#and what command to run for the task
#
#To define the time you can provide concrete values for
#minute (m), hour (h), day of month (dom), month (mon),
#and day of week (dow) or use '∗' in these fields (for 'any').#
#Notice that tasks will be started based on the cron's system
#daemon's notion of time and timezones.
#
#Output of the crontab jobs (including errors) is sent through
#email to the user the crontab file belongs to (unless redirected).
#
#For example, you can run a backup of all your user accounts
#at 5 a.m every week with:
#0 5 ∗ ∗ 1 tar ‑zcf /var/backups/home.tgz /home/
#
#For more information see the manual pages of crontab(5) and cron(8)
#
#m h dom mon dow command
0,20,40 6‑10,21‑23 ∗ 3 thu‑sat /home/ian/mycrontest.sh
System crontabs in /etc
In addition to the user crontab files in /var/spool/cron, the cron
daemon also checks /etc/crontab and any crontabs in the /etc/cron.d directory. These system crontabs have one additional field between the fifth time entry (day) and the command. This additional field specifies the user for whom the command should be run — normally, root
.
The directories such as /etc/cron.hourly and /etc/cron.daily do not contain crontabs. Instead, they contain scripts to be run with the appropriate frequency. For example, scripts in /etc/cron.daily are run daily. Scripts in /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly can be run by cron
or by the anacron
facility instead. Listing 5 shows /etc/crontab from my Mint system.
Listing 5. /etc/crontab
# /etc/crontab: system-wide crontab #Unlike any other crontab you don't have to run the crontab #command to install the new version when you edit this file #and files in /etc/cron.d. These files also have username fields, #that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin #m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) #
For the example in Listing 5, cron
runs the scripts in /etc/cron.hourly by using the run-parts
command, which runs all the executable files in a directory. The cron
daemon runs the scripts in /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly only if the anacron
command is not found in /usr/sbin. Note that the commands in this /etc/crontab example all run as root
.
The /etc/crontab file usually includes a few shell variable assignments that are set before the commands run. In , the SHELL
and PATH
variables are set. Other variables that are commonly set include HOME
for the home directory, and MAILTO
for the name of the user who should receive the mailed output.
The root user updates system crontabs by using an editor. The crontab
command maintains user crontabs only. In contrast to user crontabs, system crontabs do not need to be installed — the cron
daemon monitors /etc/crontab and the /etc/cron.d directory for changes.
Schedule periodic jobs with anacron
The cron
facility works well for systems that run continuously. For systems, such as laptops, that can be turned off or run on battery power much of the time, the anacron
facility is better for scheduling daily, weekly, or monthly jobs. The anacron
facility does not handle jobs that must run hourly or every minute.
The table of jobs for anacron
is stored in /etc/anacrontab, which has a slightly different format from /etc/crontab. Like /etc/crontab, /etc/anacrontab can contain environment settings. Each job has this four-field sequence:
- Period
- Delay
- Job identifier
- Command
The period is a number of days but can be specified as @monthly
to ensure that a job runs only once per month, regardless of the number of days in the month. The delay is the number of minutes to wait after the job is due to run before it actually starts. You can use this field to prevent a flood of jobs from running when a system first starts. The job identifier can contain any nonblank character except a slash (/
).
Both /etc/crontab and /etc/anacrontab are updated by direct editing. You cannot use the crontab
command to update these files or files in the /etc/cron.d directory.
For a simple example, I create a symbolic link, myanacrontest.sh, to my mycrontest.sh file. Now I can run the script with the myanacrontest.sh
command, which is reflected in the output. Then I add a line to /etc/anacrontab on my Mint system to run this new script daily with a delay of 10 minutes, as shown in Listing 6.
Listing 6. /etc/anacrontab
ian@attic-mint17 ~ $ ln -s mycrontest.sh myanacrontest.sh ian@attic-mint17 ~ $ ./myanacrontest.sh Running ./myanacrontest.sh. It is now 16:44:09 on Sunday ian@attic-mint17 ~ $ cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron #See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root LOGNAME=root #These replace cron's entries 1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron.monthly #Added by ian 1 10 ian-test /home/ian/myanacrontest.sh
The first day that anacron
runs the script, the mail shown in Listing 7 is sent to the root user.
Listing 7. Mail from anacron
Return‑Path: <root@attic‑mint17>
X‑Original‑To: root
Delivered‑To: root@attic‑mint17
Received: by attic‑mint17 (Postfix, from userid 0)
id 7BA621214AB; Sat, 5 Mar 2016 07:40:01 ‑0500 (EST)
From: Anacron <root@attic‑mint17>
To: root@attic‑mint17
Subject: Anacron job 'ian‑test' on attic‑mint17
Content‑Type: text/plain; charset=US‑ASCII
Message‑Id: <20160305124001.7BA621214AB@attic‑mint17>
Date: Sat, 5 Mar 2016 07:40:01 ‑0500 (EST)
Status: O
X‑UID: 2
Running /home/ian/myanacrontest.sh. It is now 07:40:01 on Saturday
Why did anacron
run the script at 7:40 a.m.? The answer on this system is in /etc/cron.d/anacron. Listing 8 shows that my Mint system runs anacron
as a service that is started by cron
at 7:30 a.m. every day. Add my 10-minute delay and you have the answer.
Listing 8. Contents of /etc/cron.d/anacron
ian@attic‑mint17 ~ $ sudo cat /etc/cron.d/anacron
#/etc/cron.d/anacron: crontab entries for the anacron package
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
30 7 ∗ ∗ ∗ root start ‑q anacron || :
What happens if the system is turned off at 7:30 a.m.? Look at the anacron
service definition in /etc/init/anacron.conf for the answer. Listing 9 shows that anacron
is also started as a service when my system starts.
Listing 9. Contents of /etc/init/anacron.conf
ian@attic‑mint17 ~ $ cat /etc/init/anacron.conf
#anacron ‑ anac(h)ronistic cron
#
#anacron executes commands at specific periods, but does not assume that
#the machine is running continuously
description "anac(h)ronistic cron"
start on runlevel 2345stop on runlevel !2345
expect fork
normal exit 0
exec anacron ‑s
Notice the -s
option on anacron
. This option tells anacron
to serialize jobs so that only one is running at a time. Serializing helps to prevent anacron
jobs from flooding your system.
Different systems have different ways of scheduling anacron
, so explore the files under /etc to fully understand how it works on your system or to find when to expect jobs to run.
Listing 10 shows some of the files and directories that Fedora 23 uses to run anacron
. Notice both the time check and the check for whether the system is on AC power.
Listing 10. anacron files on Fedora 23
[root@attic‑f23 ~``]#ls /etc/cron.d
0hourly raid‑check
[root@attic‑f23 ~``]#cat /etc/cron.d/0hourly
#Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 ∗ ∗ ∗ ∗ root run‑parts /etc/cron.hourly
[root@attic‑f23 ~]#ls /etc/cron.hourly
0anacron mcelog.cron
[root@attic‑f23 ~]#cat /etc/cron.hourly/0anacron
#!/bin/sh
#Check whether 0anacron was run today already
if test ‑r /var/spool/anacron/cron.daily; then
day=cat /var/spool/anacron/cron.daily
fi
if [ date +%Y%m%d = "$day" ]; then
exit 0;
fi
#Do not run jobs when on battery power
if test ‑x /usr/bin/on_ac_power; then
/usr/bin/on_ac_power >/dev/null 2>&1
if test $? ‑eq 1; then
exit 0
fi
fi
/usr/sbin/anacron ‑s
anacron
keeps a time stamp file in /var/spool/anacron for each job to record when the job runs. When anacron
runs, it checks to see if the required number of days has passed since a job last ran and runs the job if necessary. Listing 11 shows the contents of my /var/spool/anacron directory and the contents of the time stamp file for my ian-test job. Notice that cron.daily, cron.weekly, and ian-test all have system times in the afternoon, because I rebooted my system shortly after 3 p.m.
Listing 11. anacron time stamps
ian@attic‑mint17 ~ $ ls ‑lrt /var/spool/anacron
total 16
‑rw‑‑‑‑‑‑‑ 1 root root 9 Feb 29 07:45 cron.monthly
‑rw‑‑‑‑‑‑‑ 1 root root 9 Mar 6 15:11 cron.daily
‑rw‑‑‑‑‑‑‑ 1 root root 9 Mar 6 15:17 cron.weekly
‑rw‑‑‑‑‑‑‑ 1 root root 9 Mar 6 15:17 ian‑test
ian@attic‑mint17 ~ $ sudo cat /var/spool/anacron/ian‑test
20160306
ian@attic‑mint17 ~ $ date +%Y%m%d
20160306
The contents of each time stamp file matches the output of the date +%Y%m%ddate+%Y%m%d
command. Time stamps are normally updated by anacron
— typically when the job runs, but you might find scripts in cron.daily, cron.weekly, or cron.monthly that use the -u
option of anacron
to update time stamps without running the job.
Run jobs at specific times with at
Sometimes you need to run a job at a future time just once, rather than regularly. For this purpose you use the at
command. The commands to be run are read from stdin. The -m
option sends mail to the user even if the command has no stdout. The -v
option displays the time at which the job will run. The time is also displayed in the output.
Again, I use a symbolic link to create another name for mycrontest.sh
command. Listing 12 shows an example of running the myattest.sh
command.
Listing 12. Using the at command
ian@attic‑mint17 ~ $ ln ‑s mycrontest.sh myattest.sh
ian@attic‑mint17 ~ $ date
Sun Mar 6 21:25:21 EST 2016
ian@attic‑mint17 ~ $ at ‑v 21:30
Sun Mar 6 21:30:00 2016
warning: commands will be executed using /bin/sh
at> ~/myattest.sh
at> <EOT>
job 4 at Sun Mar 6 21:30:00 2016
Listing 13 shows the output that is mailed back to the user after the job runs. Notice that the output is more compact than the corresponding output from the cron
job.
Listing 13. Job output from at
Return‑Path: <ian@attic‑mint17>
X‑Original‑To: ian
Delivered‑To: ian@attic‑mint17
Received: by attic‑mint17 (Postfix, from userid 1000)
id DBC58122E5B; Sun, 6 Mar 2016 21:30:00 ‑0500 (EST)
Subject: Output from your job 4
To: ian@attic‑mint17
Message‑Id: <20160307023000.DBC58122E5B@attic‑mint17>
Date: Sun, 6 Mar 2016 21:30:00 ‑0500 (EST)
From: ian@attic‑mint17 (Ian Shields)
You can also specify input commands from a file by using the -f
option. If you specify the myattest.sh file as input, the at
command reads the commands from within the file rather than executing the file as a script. To use sh
to run myattest.sh
as a command — rather than running the individual commands within the myattest.sh file — create a small file to run the command:
ian@attic‑mint17 ~ $ echo ~/myattest.sh > run‑my‑attest
You can specify time values in many ways. Listing 14 shows a few examples. See the man page for at
; or the file /usr/share/doc/at/timespec; or a file such as /usr/share/doc/at/timespec, which contains an abbreviated version of the yacc
grammar that at
uses.
Listing 14. Time values with the at command
ian@attic‑mint17 ~ $ date
Sun Mar 6 21:43:17 EST 2016
ian@attic‑mint17 ~ $ at ‑f run‑my‑attest 10pm tomorrow
warning: commands will be executed using /bin/sh
job 12 at Mon Mar 7 22:00:00 2016
ian@attic‑mint17 ~ $ at ‑f run‑my‑attest 2:00 tuesday
warning: commands will be executed using /bin/sh
job 13 at Tue Mar 8 02:00:00 2016
ian@attic‑mint17 ~ $ at ‑f run‑my‑attest 16:00 march 9
warning: commands will be executed using /bin/sh
job 14 at Wed Mar 9 16:00:00 2016
ian@attic‑mint17 ~ $ at ‑f run‑my‑attest 16:00 next week
warning: commands will be executed using /bin/sh
job 15 at Sun Mar 13 16:00:00 2016
ian@attic‑mint17 ~ $ at ‑f run‑my‑attest now + 1 hour
warning: commands will be executed using /bin/sh
job 16 at Sun Mar 6 22:44:00 2016
The at
command also has a -q
option. Increasing the queue increases the nice
value for the job. Queue values consist of a single letter ranging from a
to z
and then A
to Z
. The default value is a
.
The Linux batch
command is similar to the at
command, except that batch
jobs are run only when the system load is low enough. The default queue value for batch
jobs is b
. See the man pages for more details on these features.
Manage scheduled jobs
In this section, I show you how to manage your scheduled cron
and at
jobs. You can find out what jobs are scheduled and which commands they will run. You can also delete jobs from the schedule.
Listing scheduled jobs
You manage your cron
and at
jobs by using the crontab
command. Use the -l
option to display your crontab, and use the at -lat-l
or atq
command to display the jobs that you queued with the at
command. Listing 15 shows examples.
Listing 15. Displaying scheduled jobs
ian@attic‑mint17 ~ $ crontab ‑l
#Edit this file to introduce tasks to be run by cron.
#
#Each task to run has to be defined through a single line
#indicating with different fields when the task will be run
#and what command to run for the task
#
#To define the time you can provide concrete values for
#minute (m), hour (h), day of month (dom), month (mon),
#and day of week (dow) or use '∗' in these fields (for 'any').#
#Notice that tasks will be started based on the cron's system
#daemon's notion of time and timezones.
#
#Output of the crontab jobs (including errors) is sent through
#email to the user the crontab file belongs to (unless redirected).
#
#For example, you can run a backup of all your user accounts
#at 5 a.m every week with:
#0 5 ∗ ∗ 1 tar ‑zcf /var/backups/home.tgz /home/
#
#For more information see the manual pages of crontab(5) and cron(8)
#
#m h dom mon dow command
0,20,40 6‑10,21‑23 ∗ 3 thu‑sat /home/ian/mycrontest.sh
ian@attic‑mint17 ~ $ atq
16 Sun Mar 6 22:44:00 2016 a ian
15 Sun Mar 13 16:00:00 2016 a ian
14 Wed Mar 9 16:00:00 2016 a ian
13 Tue Mar 8 02:00:00 2016 a ian
12 Mon Mar 7 22:00:00 2016 a ian
If you want to review the actual command that is scheduled for execution by at
, use the at
command with the -c
option and the job number. You will notice that most of the environment that was active at the time the at
command was issued is saved with the scheduled job. Listing 16 shows part of the output for job 12.
Listing 16. Using at -c with a job number
ian@attic‑mint17 ~ $ at ‑c 12
#!/bin/sh
#atrun uid=1000 gid=1000
#mail ian 0
umask 22
XDG_VTNR=8; export XDG_VTNR
SSH_AGENT_PID=2143; export SSH_AGENT_PID
XDG_SESSION_ID=c1; export XDG_SESSION_ID
QT_STYLE_OVERRIDE=gtk; export QT_STYLE_OVERRIDE
GPG_AGENT_INFO=/run/user/1000/keyring‑cPt8Dv/gpg:0:1; export GPG_AGENT_INFO
VTE_VERSION=3409; export VTE_VERSION
XDG_SESSION_COOKIE=67f75db84cdfd0e39f29366b55c8cbcc‑1457296158.398615‑1040075348;
export XDG_SESSION_COOKIE
GJS_DEBUG_OUTPUT=stderr; export GJS_DEBUG_OUTPUT
WINDOWID=41945022; export WINDOWID
GNOME_KEYRING_CONTROL=/run/user/1000/keyring‑cPt8Dv; export GNOME_KEYRING_CONTROL
GJS_DEBUG_TOPICS=JS\ ERROR\;JS\ LOG; export GJS_DEBUG_TOPICS
USER=ian; export USER
...
LESSCLOSE=/usr/bin/lesspipe\ %s\ %s; export LESSCLOSE
TEXTDOMAINDIR=/usr/share/locale/; export TEXTDOMAINDIR
COLORTERM=gnome‑terminal; export COLORTERM
XAUTHORITY=/home/ian/.Xauthority; export XAUTHORITY
cd /home/ian || {
echo 'Execution directory inaccessible' >&2
exit 1
}
/home/ian/myattest.sh
Deleting scheduled jobs
You can delete all scheduled cron
jobs by using the cron
command with the -r
option:
ian@attic‑mint17 ~ $ crontab ‑r
ian@attic‑mint17 ~ $ crontab ‑l
no crontab for ian
To delete system cron
or anacron
jobs, edit /etc/crontab or /etc/anacrontab, or edit or delete files in the /etc/cron.d directory. If you delete anacron
jobs, remember to delete the associated time stamp files from /var/spool/anacron. The anacron
time stamp files are not deleted automatically.
You can delete one or more jobs that were scheduled with the at
command by using the atrm
command with the job number. The at
command with the -r
or -d
option is an alias for atrm
. Separate multiple jobs by spaces. Listing 17 shows an example.
Listing 17. Displaying and removing jobs with atq and atrm
ian@attic‑mint17 ~ $ atq
16 Sun Mar 6 22:44:00 2016 a ian
15 Sun Mar 13 16:00:00 2016 a ian
14 Wed Mar 9 16:00:00 2016 a ian
13 Tue Mar 8 02:00:00 2016 a ian
12 Mon Mar 7 22:00:00 2016 a ian
ian@attic‑mint17 ~ $ atrm 13
ian@attic‑mint17 ~ $ atrm 16 12
ian@attic‑mint17 ~ $ atq
15 Sun Mar 13 16:00:00 2016 a ian
14 Wed Mar 9 16:00:00 2016 a ian
Configure user access to job scheduling
If the /etc/cron.allow file exists, any non-root user must be listed in it to be able to use crontab
and the cron
facility. If /etc/cron.allow does not exist but /etc/cron.deny does exist, a non-root user who is listed in it cannot use crontab
or the cron
facility. If neither of these files exists, then (undocumented) site-dependent configuration parameters determine whether only the superuser is allowed to use crontab
, or whether all users can use it. If no cron.allow file exists and an empty cron.deny file exists, no users are prohibited from using crontab
— equivalently, all users can use it.
The corresponding /etc/at.allow and /etc/at.deny files have similar effects for the at
facility.
This concludes your introduction to user and group account management.