Browse Courses

Cron Jobs

Learn about Linux cron utility for scheduling recurring jobs. Master crontab syntax, scheduling commands, managing job lists, and automating system tasks on Unix-like operating systems.

This document explores the cron utility in Linux and Unix-like systems for automating recurring tasks. It covers the relationships between cron, crond daemon, and crontab files, explains the crontab syntax with practical examples, and demonstrates how to schedule, view, and remove jobs for system maintenance, data processing, and other routine operations.


Introduction to Cron Job Scheduling

Cron is a time-based job scheduler in Unix-like operating systems that enables users to schedule commands or scripts to run automatically at specified times or intervals. It is particularly useful for system administrators, data engineers, and developers who need to automate routine tasks.

Key Components of the Cron System

The cron system consists of several interconnected components:

ComponentDescription
cronThe general name of the utility that runs scheduled jobs consisting of shell commands or scripts
crondThe daemon (background service) that interprets crontab files every minute and submits the corresponding jobs to cron at their scheduled times
crontabBoth a file containing jobs and schedule data, and a command that invokes a text editor to edit that file

Common Use Cases

Cron jobs are commonly used for:

  • Running system maintenance tasks (log rotation, cleanup)
  • Scheduling backups
  • Running data processing scripts at specific times
  • Generating periodic reports
  • Monitoring system health
  • Automating software updates

Working with Crontab

The crontab command is used to create, view, and edit the scheduling information for cron jobs.

Editing Crontab

To create or edit a crontab file:

1crontab -e

This command opens the default text editor (often vi or nano) with the current user’s crontab file. If no crontab exists yet, it creates a new one.

Crontab Syntax

The basic syntax for a crontab entry is:

1* * * * * command

Each asterisk represents a specific time element:

PositionFieldAllowed Values
1Minute0-59
2Hour0-23
3Day of Month1-31
4Month1-12 or JAN-DEC
5Day of Week0-6 or SUN-SAT (0 or 7 is Sunday)

The command portion can be any shell command or script.

Special Characters in Crontab

Several special characters can be used in the time fields:

CharacterDescriptionExample
*Any value* * * * * runs every minute
,Value list separator1,15 * * * * runs at minute 1 and 15
-Range of values1-5 * * * * runs every minute from 1 through 5
/Step values*/5 * * * * runs every 5 minutes

Example Crontab Entries

Here are some practical examples of crontab entries:

Run a backup script every Sunday at 2 AM:

10 2 * * 0 /path/to/backup.sh

Execute a data loading script at midnight every day:

10 0 * * * /path/to/load_data.sh

Append the current date to a file at 3:30 PM every Sunday:

130 15 * * 0 date >> /path/to/sundays.txt

Managing Cron Jobs

Once cron jobs are set up, they can be managed using various crontab options.

Viewing Cron Jobs

To list all scheduled cron jobs for the current user:

1crontab -l

This displays the contents of the user’s crontab file, showing all scheduled jobs and their timing.

To see only the actual job entries without comments, pipe the output through another command:

1crontab -l | tail -n 10

Removing Cron Jobs

To remove specific cron jobs:

  1. Open the crontab file with crontab -e
  2. Delete the line containing the job to be removed
  3. Save and exit the editor

To remove all cron jobs for the current user:

1crontab -r

Example Workflow

The typical workflow for managing cron jobs is:

  1. Open the crontab editor:

    1crontab -e
    
  2. Add or modify job entries using the proper syntax

    130 15 * * 0 date >> /path/to/sundays.txt
    20 0 * * * /path/to/load_data.sh
    30 2 * * 0 /path/to/backup.sh
    
  3. Save and exit the editor (in nano: Ctrl+X, then Y to confirm)

  4. Verify the jobs are properly scheduled:

    1crontab -l
    

Conclusion

The cron utility provides a powerful way to automate recurring tasks in Unix-like operating systems. By understanding the components of the cron system (cron, crond, and crontab) and mastering the crontab syntax, users can effectively schedule commands and scripts to run at specific times. Managing cron jobs through the crontab command ensures that automated tasks remain organized and functional, saving time and reducing the potential for human error in routine operations.


FAQs

Cron is a time-based job scheduler in Unix-like operating systems that enables users to schedule commands or scripts to run automatically at specified times or intervals. It’s a utility that runs scheduled jobs consisting of shell commands or scripts, making it essential for automating routine tasks like system maintenance, backups, and data processing.

These three terms refer to different components of the cron system:

  • cron: The general name of the utility that runs scheduled jobs
  • crond: The daemon (background service) that interprets crontab files every minute and submits jobs to cron at their scheduled times
  • crontab: Both a file containing jobs and schedule data, and a command that invokes a text editor to edit that file

To edit a user’s crontab file, use the command crontab -e. This opens the default text editor with the current user’s crontab file. If no crontab exists yet, it creates a new one. After making changes, save and exit the editor to apply the new schedule.

Field PositionMeaning
A. First field1. Day of month (1-31)
B. Second field2. Hour (0-23)
C. Third field3. Minute (0-59)
D. Fourth field4. Month (1-12)
E. Fifth field5. Day of week (0-6, where 0 is Sunday)
A-3, B-2, C-1, D-4, E-5. The correct order of crontab fields is: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday).

Click to see answer
130 17 * * 1-5 /path/to/daily_report.sh

This crontab entry sets the job to run at minute 30, hour 17 (5:30 PM), on any day of month (), any month (), but only on weekdays (1-5, which represents Monday through Friday).

  1. Skip this field
  2. Run once per hour
  3. Match any value for this field
  4. Disable this part of the schedule
(3) Match any value for this field. The asterisk (*) is a wildcard that means “any” or “all possible values” for that particular time unit. For example, an asterisk in the “month” field means “every month.”

The command crontab -r will safely remove only one specific job from the crontab file.

False. The command crontab -r removes the entire crontab file for the current user without confirmation, deleting all scheduled jobs. To remove a specific job, you must use crontab -e to edit the file, delete only the line containing the unwanted job, and then save the file.

To view all currently scheduled cron jobs for a user, use the command crontab -l. This displays the contents of the user’s crontab file, showing all scheduled jobs and their timing. To see only the actual job entries without comments, you can pipe the output through another command, such as crontab -l | tail -n 10.

Click to see answer

This crontab entry runs the script /scripts/monthly_cleanup.sh at midnight (0 hours, 0 minutes) on the first day of every month.

Breaking down the fields:

  • 0 - Minute: 0 (top of the hour)
  • 0 - Hour: 0 (midnight)
  • 1 - Day of month: 1 (first day of the month)
  • * - Month: * (every month)
  • * - Day of week: * (any day of the week)

This is commonly used for monthly maintenance tasks like archiving logs or generating monthly reports.

  1. The asterisk (*) means “any value” for a field
  2. The comma (,) can be used to specify a list of values
  3. The hyphen (-) indicates a range of values
  4. The forward slash (/) in a field means “run the command with root privileges”
(4) is incorrect. The forward slash (/) in a crontab field is used to specify step values, not to run commands with root privileges. For example, */5 in the minutes field means “every 5 minutes”. To run commands with root privileges, you would need to edit the root user’s crontab with sudo crontab -e.

Click to see answer

If a cron job contains errors in the command or script, the job will still attempt to run at the scheduled time, but it will fail during execution. By default, cron sends an email with any error output to the user who owns the crontab. However, if email is not properly configured on the system, these error messages might go unnoticed.

To troubleshoot failing cron jobs, it’s good practice to:

  1. Redirect both standard output and error to a log file
  2. Test the command manually before adding it to crontab
  3. Include the full path to all commands and files in the cron job

Click to see answer

To set up a cron job to run every 15 minutes, use this crontab entry:

1*/15 * * * * /path/to/command

The */15 in the minutes field tells cron to run the command when the minute value is divisible by 15 (0, 15, 30, 45), effectively running every quarter hour throughout the day.

  1. crontab -d
  2. crontab -r
  3. crontab -x
  4. crontab --remove
(2) crontab -r is the command that permanently deletes all scheduled cron jobs for the current user by removing the entire crontab file without confirmation. This is why it should be used with caution.

Several issues could prevent cron jobs from running as expected:

  1. Incorrect path: Cron runs with a limited environment, so commands need absolute paths
  2. Permission problems: The user’s cron job might not have permission to access certain files or directories
  3. Syntax errors: The crontab entry might have incorrect formatting
  4. Crond service not running: The cron daemon might be stopped or disabled
  5. Script not executable: If running a script, it needs execute permissions (chmod +x script.sh)
  6. Environment variables: Cron doesn’t load the user’s full environment, so scripts depending on environment variables might fail

Debugging typically involves checking system logs (/var/log/syslog or /var/log/cron), redirecting output to a log file in the cron job, and testing commands manually.

Click to see answer

If a cron job is scheduled to run when the system is powered off, the job will simply not run. Unlike some other scheduling systems (such as anacron), standard cron does not have a mechanism to “catch up” on missed jobs when the system comes back online.

If running jobs even after system downtime is important, there are alternatives:

  1. Use anacron instead of cron for jobs that need to run daily, weekly, or monthly
  2. Implement custom logic in scripts to check when they last ran
  3. Use systemd timers which can have the persistent option enabled

Click to see answer

User crontab files are typically stored in the /var/spool/cron/crontabs/ directory on most Linux systems. Each user’s crontab file is named after their username. For example, the crontab for user “john” would be stored as /var/spool/cron/crontabs/john.

However, users should not edit these files directly. Always use the crontab -e command, which handles proper permissions and notifies the cron daemon about changes.