VMware ESXi and vSphere Cluster Management

Schedule Jobs with Cron on Linux

Learn how cron works on Linux, write system and user crontab entries, use schedule operators, and troubleshoot recurring maintenance jobs.

Cron is the Linux scheduling service used to run commands automatically at scheduled intervals. A configured command or script is called a cron job. Cron is useful for recurring maintenance such as log rotation, temporary-file removal, cleanup commands, backups, and running your own scripts.

How Cron Works

The cron daemon is a background process that checks cron scheduling configuration regularly, typically once per minute. When the current time matches a job's schedule, the daemon starts that job using the configured execution account.

A crontab is a cron table: a file or managed list of scheduled job entries. Linux systems commonly have system-wide crontabs, while each user can also have a personal crontab.

Typical Uses for Cron

• Running log rotation and other system-maintenance tasks.
• Removing unneeded temporary files.
• Running regular cleanup commands.
• Executing a user's own scripts or programs at defined times.

System Cron Jobs and User Cron Jobs

A system cron job is a system-wide scheduled task, generally used for administration and maintenance. Its entry explicitly specifies the Linux account that will run the command. Administrative jobs often run as root, the privileged Linux administrative account.

A user cron job is a scheduled task owned and executed by an individual user. It runs as the owner of that user's personal crontab, so the entry does not need an account field.

The System Crontab

/etc/crontab is a system-wide cron configuration file. It is a text file containing scheduled command entries. Fields in an entry are separated by whitespace.

System crontab entries have seven fields: five time fields, an account field, and the command:

minute hour day-of-month month day-of-week account command

The account field appears between the day-of-week field and the command. This is the key syntax difference from a user's personal crontab.

Cron Time-Field Syntax

The first five fields determine when a job is eligible to run. The final command field contains the command to execute. Use a single value, an asterisk, a list, or a range in each time field.

Asterisk: Match Every Value

An asterisk (*) matches every valid value in its field. For example, * in the hour field means every hour, while * in the month field means every month.

* * * * * command

This syntax illustration matches every minute because all five scheduling fields match every possible value. Do not install it casually: it starts the command once per minute.

Lists: Choose Specific Values

A list is a comma-separated set of allowed values. The fragment 0,3,5 matches any one of those values in the field where it appears. In the hour field, it means 00:00, 03:00, and 05:00.

Ranges: Choose an Inclusive Span

A range is a hyphen-separated span of values. The fragment 8-15 matches every hour from 08:00 through 15:00 when used in the hour field. The same notation works with minutes, dates, months, and weekdays within their permitted ranges.

Reading a Complete System Cron Entry

00 21 * * * root rm /home/bob/trash/*

Read this entry from left to right:

1. 00 in the minute field means minute zero.
2. 21 in the hour field means 21:00, or 9:00 p.m.
3. The first * means every day of the month.
4. The second * means every month.
5. The third * means every day of the week.
6. root is the account used to run the command.
7. rm /home/bob/trash/* is the command. Its shell wildcard selects entries in Bob's trash directory.

Therefore, this job runs the removal command as root at 21:00 every day, regardless of the month or weekday. Because it uses a privileged account and deletes files, verify the path and command before saving it.

Creating a User Cron Job

Use a personal crontab when a task should run as your own user account. Open the current user's crontab with:

crontab -e

Add one job per line. A user crontab has five schedule fields followed directly by the command:

minute hour day-of-month month day-of-week command

For example:

30 8 * * 1 /home/alex/bin/report.sh

This runs /home/alex/bin/report.sh at 08:30 on day 1 of the week, where the weekday numbering follows the system's cron convention. The command runs as the user who owns the crontab, not as root.

To view the current user's configured jobs, use:

crontab -l

The system and user formats can be compared directly:

System: minute hour day-of-month month day-of-week account command
User:   minute hour day-of-month month day-of-week command

Checking Cron Activity

Cron activity can be investigated through system logging. Depending on the Linux distribution and logging configuration, cron-related messages may be recorded in /var/log/messages.

grep cron /var/log/messages

Log entries can confirm that the daemon invoked a job. They can also provide clues when a job did not behave as expected, such as an invalid entry or an execution failure. Some distributions use a different log file or a system journal, so the available logging configuration may vary.

Troubleshooting Cron Jobs

The Command Does Not Run at the Expected Time

• Verify that every time field uses a permitted value: minutes are 0-59, hours are 0-23, days of the month are 1-31, months are 1-12, and weekdays are 0-7.
• Check that asterisks, lists, and ranges express the intended schedule.
• Confirm that the entry is in the correct system or user crontab.
• Inspect applicable system logs, including /var/log/messages where that file is used.

A System Entry Is Rejected or Behaves Incorrectly

• Confirm that the account field appears between the day-of-week field and the command.
• Ensure the intended account, such as root, is spelled correctly.
• Ensure all fields are separated by whitespace.

The Job Has Unexpected Permissions

• Remember that a user job runs as the owner of that user's crontab.
• Use a system cron job only when the task genuinely requires the specified administrative account.
• Check that the execution account can access the files and commands involved.

A Cleanup Job Deletes Too Much

• Review wildcard use in both the cron schedule and the shell command.
• Test the file-selection behavior before scheduling a removal command.
• Confirm that the target directory path is exact, especially when the job runs as root.

Practical Checklist

1. Decide whether the job belongs in a system crontab or your personal crontab.
2. Write the five time fields using valid ranges, lists, ranges, or asterisks.
3. For a system entry, add the execution account before the command.
4. Use exact paths for scripts, files, and directories.
5. Review permissions and dangerous commands before enabling the job.
6. Use crontab -l to verify a personal crontab.
7. Inspect applicable system logs if the job does not run or produces unexpected results.

For a concise reference to this lesson, see Schedule Jobs With Cron.