Learn everything about Linux/Unix schedulers i.e. cron and at. Know how to schedule cronjobs and at jobs, their configuration files, log files.

Unix or Linux comes with native in-build job scheduler i.e. cron and at. Out of which cron used to schedule tasks to repeat over some period while at used to execute the job at a specific time one time.

Cron

Cron enables administrators/users to execute a particular script or command at a given time of choice repetitively. It’s a daemon that runs in the background whenever system clock configured time it executes respective script or command. It can be checked if running with ps/service command.

# ps -ef |grep -i cron
root      2390     1  0 Mar17 ?        00:01:24 crond
root      8129  8072  0 09:50 pts/0    00:00:00 grep -i cron
# service crond status
crond (pid  2390) is running...

Configurations

Cron saves commands/scripts and related schedules in a file called crontab. Normally crontab can be found in path /var/spool/cron and file with a username (root user crontab file can be seen in the below example). These are plain text files that can be viewed using cat, more commands and can be edited using a text editor.

# pwd
/var/spool/cron
# ll
total 4
-rw------- 1 root root 99 Jul 31  2015 root
# cat root
00 8 * * 1 /scripts/log_collection.sh

But, it’s not advisable to edit crontab file with a text editor, you need to use crontab -e <username> command to edit it so that syntax can be verified before saving. This command opens a crontab file in a native text editor only.

Cron access can be given a user basis. The administrator can enable or disable cron access to a particular user. There are two files cron.allow, cron.deny; either one of which will exist on the server. These are files with usernames only. No special file format/syntax follows within. If both files are missing then the only superuser is allowed to use cron.

If cron.allow exists on the server then only users specified in this file are allowed to use cron, rest all are denied. And if it exists and empty then all are denied.

If cron.deny exists then only users specified in it are not allowed to use cron, rest all are allowed. And if it exists and empty then all are allowed.

Syntax

Let’s see the syntax for the crontab file and commands.

A crontab file has 6 fields separated by space to be filled in. Those are as below :

where,

• Minute: Timestamp in 24 hrs format
• Hours: Timestamp in 24 hrs format
• Day of month: Date in dd format
• Month: Month number in mm format or Jan, Feb format.
• Day of week: Numeric/text day of the week. 0 or 7 being Sunday or Sun, Mon, etc.

These fields also support a series of values or multiple values example 1,2,3 or 1-4. When multiple time values defined then the event will happen whenever the clock hits one of the values.

Default cron definitions i.e. path or shell used to execute commands/scripts in crontabs etc are defined in /etc/crontab file. See example below :

# cat /etc/crontab
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-name command to be executed

Crontab commands

We have a crontab command with several options to play around configurations.

• -u Specify user
• -l to view specified user’s crontab
• -e to edit specified user’s crontab
• -r to remove specified user’s crontab
• -i Interactive removal. Should be used with -r

If a new crontab is being set then the system will show using empty crontab for the user!

# crontab -u testuser -e
no crontab for testuser - using an empty one
crontab: installing new crontab
# crontab -u testuser-l
00 8 * * 1 echo test
# crontab -u testuser -i -r
crontab: really delete testuser's crontab? y
# crontab -u testuser -l
no crontab for testuser

Cron logs

All activities by cron daemon are logged in logfile /var/log/cron. It includes crontab alterations and cron daemon executions. Let’s look at the file

# tail /var/log/cron
Nov 21 10:25:36 oratest02 crontab[29364]: (root) BEGIN EDIT (testuser)
Nov 21 10:25:48 oratest02 crontab[29364]: (root) REPLACE (testuser)
Nov 21 10:25:48 oratest02 crontab[29364]: (root) END EDIT (testuser)
Nov 21 10:26:52 oratest02 crontab[30139]: (root) LIST (testuser)
Nov 21 10:27:46 oratest02 crontab[30695]: (root) DELETE (testuser)
Nov 21 10:27:53 oratest02 crontab[30697]: (root) LIST (testuser)
Nov 21 10:30:01 oratest02 CROND[31983]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Nov 22 10:40:01 oratest02 CROND[6166]: (root) CMD (/usr/lib64/sa/sa1 1 1)

In the above example, you can see, crontab alteration is being logged with what actions took place. Those logs are against the crontab field where first braces show the user who did alterations and last braces show which user’s crontab was altered. In the last two, you can see cron commands being executed by cron daemon according to schedule hence logged against CROND. This file is very helpful in troubleshooting issues related to cron executions.

at

At enables administrators/users to execute a particular script or command at a given time of choice only once. It can also be termed as one-time task scheduling.  Same as crond, a daemon for at is atd which runs in background. This can be checked using ps or service commands.

# ps -ef |grep -i atd
root      2403     1  0 Mar17 ?        00:00:00 /usr/sbin/atd
root     13568  8072  0 10:51 pts/0    00:00:00 grep -i atd
# service atd status
atd (pid  2403) is running...

Configurations

at stores submitted jobs in files located at /var/spool/at where file names are system generated and unlike crontabs these files can not be read.

# pwd
/var/spool/at
# ll
total 12
-rwx------  1 root   root 2994 Nov 22 10:57 a000010178544d
-rwx------  1 root   root 2989 Nov 22 11:00 a000020178548c
drwx------. 2 daemon daemon  4096 Jan 30  2012 spool

at access also can be given a user basis. It also has at.allow and at.deny files and those works same as cron.allow and cron.deny files we saw earlier in this post.

Syntax

at command should be supplied with the time you prefer to execute the command. Once given in proper format, it will present you with a prompt. This prompt takes command inputs that need to be executed at a given time. Once finished entering commands/ scripts one can simply press ctrl+d to exit out of at prompt and save the job. Observe a new file that is being generated at the above-mentioned path once you submit the job. at commands takes numerous types of time formats like noon, midnight, now + 2 hours, now + 20 minutes, tomorrow, next Monday, etc. If you enter the wrong format it will return the “garbled time” error message.

# at +2 hours
syntax error. Last token seen: +
Garbled time
# at now + 2 hour
at> echo hello
at> <EOT>
job 2 at 2016-11-22 13:00

To view currently queued jobs in at scheduler run atq or at -l command. It shows the output with numbering in the first column. The second field is about a time when the execution will happen and the last field is the username.

# atq
2       2016-11-22 13:00 a root
1       2016-11-22 11:57 a root

# at -l
2       2016-11-22 13:00 a root
1       2016-11-22 11:57 a root

To remove a particular job from queue atrm command is used. It should be supplied with serial number of the job. In the below example, we removed job number 2. You can see its vanished from the queue. The same can be achieved using at -r command instead of atrm.

# atrm 1

# at -l
2       2016-11-22 13:00 a root

at logs:

at daemon is very much regressive in terms of logging. Normally it does not log anything anywhere about its job queue alterations or job executions. Only fatal errors related to daemon are logged in Syslog only. Even if we turn debugging on, it logs information which is merely informative to look at.