Automate system administration tasks by scheduling jobs

Overview

In this tutorial, learn to:

• Use the cron and anacron commands to run jobs at regular intervals
• Use the at command to run jobs at a specific time
• Manage cron and at jobs
• Configure user access to the cron and at 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 anachronistic cron) 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.

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.

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.

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.

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.

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.

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.

 # /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.

 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.

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.

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.

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.

[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.

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.

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.

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.

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.

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.

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.

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.