Automation with Cron job on Centos 8

Adapted from digital ocean reference.

Introduction

Cron is a time-based job scheduling daemon found in Unix-like operating systems, including Linux distributions. Cron runs in the background and tasks scheduled with cron, referred to as “cron jobs,” are executed automatically, making cron useful for automating maintenance-related tasks.

crond is the cron daemon that runs in the background and runs the jobs as schedule. Check to see if the crond service is running in the background.

$ sudo systemctl status crond
 ● crond.service - Command Scheduler
    Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
    Active: active (running) since Tue 2020-03-24 15:11:52 AEDT; 1 weeks 5 days ago
  Main PID: 1280 (crond)
     Tasks: 1 (limit: 23592)
    Memory: 2.2M
    CGroup: /system.slice/crond.service
            └─1280 /usr/sbin/crond -n
.
.
.

Background

Cron jobs are recorded and managed in a special file known as a crontab. Each user profile on the system can have their own crontab where they can schedule jobs, which is stored under /var/spool/cron/.

The schedule component of the syntax is broken down into 5 different fields, which are written in the following order:

Field	Allowed Values
minute	0-59
hour	0-23
Day of the month	1-31
month	1-12 or JAN-DEC
Day of the week	0-6 or SUN-SAT

Together, tasks scheduled in a crontab are structured like this:

minute hour day_of_month month day_of_week command_to_run

Example of a cron expression. This expression runs the command mysqldump -u user -p%pass database | gzip > /home/saeed/project/db_backups/prjdb_date +\%Y-\%m-\%d_\%H\%M\%S.sql.gz everyday Tuesday at 11:45 PM:

45 23 * * 2 mysqldump -u user -p%pass database | gzip > /home/saeed/project/db_backups/prjdb_`date +\%Y-\%m-\%d_\%H\%M\%S`.sql.gz

Some special characters you can include in the schedule component of a cron expression to make scheduling easier:

• *: An asterisk is a wildcard variable that represents “all.” Thus, a task scheduled with * * * * * ... will run every minute of every hour of every day of every month.
• ,: Commas break up scheduling values to form a list. If you want to have a task run at the beginning and middle of every hour, rather than writing out two separate tasks (e.g., 0 * * * * ... and 30 * * * * ...), you could achieve the same functionality with one (0,30 * * * * ...).
• -: A hyphen represents a range of values in the schedule field. Instead of having 30 separate scheduled tasks for a command you want to run for the first 30 minutes of every hour (as in 0 * * * * ..., 1 * * * * ..., 2 * * * * ..., and so on), you could just schedule it as.0-29 * * * * ...
• /: You can use a forward slash with an asterisk to express a step value. For example, instead of writing out eight separate cron tasks to run a command every three hours (as in, 0 0 * * * ..., 0 3 * * * ..., 0 6 * * * ..., and so on), you could schedule it to run like this: 0 */3 * * * ....

Note: You cannot express step values arbitrarily; you can only use integers that divide evenly into the range allowed by the field in question. For instance, in the “hours” field you could only follow a forward slash with 1, 2, 3, 4, 6, 8, or 12.

Here are some more examples of how to use cron’s scheduling component:

• * * * * * – Run the command every minute.
• 12 * * * * – Run the command 12 minutes after every hour.
• 0,15,30,45 * * * * – Run the command every 15 minutes.
• */15 * * * * – Run the command every 15 minutes.
• 0 4 * * * – Run the command every day at 4:00 AM.
• 0 4 * * 2-4 – Run the command every Tuesday, Wednesday, and Thursday at 4:00 AM.
• 20,40 */8 * 7-12 * – Run the command on the 20th and 40th minute of every 8th hour every day of the last 6 months of the year.

Managing Crontabs

You can edit your crontab with the following command:

• crontab -e

This will open up your crontab in your user profile’s default text editor.

If you’d like to view the contents of your crontab, but not edit it, you can use the following command:

• crontab -l

You can erase your crontab with the following command:

Warning: The following command will not ask you to confirm that you want to erase your crontab. Only run it if you are certain that you want to erase it.

• crontab -r

This command will delete the user’s crontab immediately. However, you can include the -i flag to have the command prompt you to confirm that you actually want to delete the user’s crontab:

• crontab -r -i

Output

crontab: really delete sammy's crontab?

When prompted, you must enter y to delete the crontab or n to cancel the deletion.

Managing Cron Job Output

Because cron jobs are executed in the background, it isn’t always apparent that they’ve run successfully. Now that you know how to use the crontab command and how to schedule a cron job, you can start experimenting with some different ways of redirecting the output of cron jobs to help you track that they’ve been executed successfully.

If you have a mail transfer agent — such as Sendmail — installed and properly configured on your server, you can send the output of cron tasks to the email address associated with your Linux user profile. You can also manually specify an email address by providing a MAILTO setting at the top of the crontab.

For example, you could add the following lines to a crontab. These include a MAILTO statement followed by an example email address, a SHELL directive that indicates the shell to run (bash in this example), a HOME directive pointing to the path in which to search for the cron binary, and a single cron task:

. . .

MAILTO="example@digitalocean.com"
SHELL=/bin/bash
HOME=/

* * * * * echo ‘Run this command every minute’

This particular job will return “Run this command every minute,” and that output will get emailed every minute to the email address specified after the MAILTO directive.

You can also redirect a cron task’s output into a log file or into an empty location to prevent getting an email with the output.

To append a scheduled command’s output to a log file, add >> to the end of the command followed by the name and location of a log file of your choosing, like this:

* * * * * echo ‘Run this command every minute’ >> /directory/path/file.log

Let’s say you want to use cron to run a script but keep it running in the background. To do so, you could redirect the script’s output to an empty location, like /dev/null which immediately deletes any data written to it. For example, the following cron job executes a PHP script and runs it in the background:

* * * * * /usr/bin/php /var/www/domain.com/backup.php > /dev/null 2>&1

This cron job also redirects standard error — represented by 2 — to standard output (>&1). Because standard output is already being redirected to /dev/null, this essentially allows the script to run silently. Even if the crontab contains a MAILTO statement, the command’s output won’t be sent to the specified email address.

Restricting Access

You can manage which users are allowed to use the crontab command with the cron.allow and cron.deny files, both of which are stored in the /etc/ directory. If the cron.deny file exists, any user listed in it will be barred from editing their crontab. If cron.allow exists, only users listed in it will be able to edit their crontabs. If both files exist and the same user is listed in each, the cron.allow file will override cron.deny and the user will be able to edit their crontab.

For example, to deny access to all users and then give access to the user ishmael, you could use the following command sequence:

• sudo echo ALL >>/etc/cron.deny
• sudo echo ishmael >>/etc/cron.allow

First, we lock out all users by appending ALL to the cron.deny file. Then, by appending the username to the cron.allow file, we give the ishmael user profile access to execute cron jobs.

Note that if a user has sudo privileges, they can edit another user’s crontab with the following command:

sudo crontab -u user -e

However, if cron.deny exists and user is listed in it and they aren’t listed in cron.allow, you’ll receive the following error after running the previous command: Output

The user user cannot use this program (crontab)

By default, most cron daemons will assume all users have access to cron unless either cron.allow or cron.deny exists.

Special Syntax

There are also several shorthand commands you can use in your crontab file to help streamline job scheduling. They are essentially shortcuts for the equivalent numeric schedule specified:

Shortcut	Shorthand for
@hourly	0 * * * *
@daily	0 0 * * *
@weekly	0 0 * * 0
@monthly	0 0 1 * *
@yearly	0 0 1 1 *

Note: Not all cron daemons can parse this syntax (particularly older versions), so double-check it works before you rely on it.

Additionally, the @reboot shorthand will run whatever command follows it any time the server starts up:

@reboot echo "System start up"

Using these shortcuts whenever possible can help make it easier to interpret the schedule of tasks in your crontab.