Crontab Command on Linux with Examples

In this tutorial, we will show you learn crontab command on Linux with examples. Linux system administrators and power users rely heavily on task automation to maintain efficient systems. Among the many utilities available, the crontab command stands out as one of the most powerful and versatile tools for scheduling recurring tasks. Whether you need to run system backups at midnight, perform log rotations weekly, or execute scripts at specific intervals, crontab provides a robust solution that has been a cornerstone of Linux systems for decades.

Understanding Cron and Crontab

Cron is a time-based job scheduling daemon that runs in the background of Linux systems. It executes commands or scripts automatically at specified dates and times. The name “cron” originates from the Greek word “chronos,” meaning time, reflecting its primary function of time-based task execution.

Crontab, short for “cron table,” is both a command and a file that contains the schedule of jobs to be run. Each user on a Linux system can have their own crontab file, and commands in this file will be executed under that user’s permissions.

The distinction between cron and crontab is important:

• Cron is the daemon (background service) that checks for and executes scheduled tasks
• Crontab is the utility for creating, editing, and managing these scheduled tasks

The crontab files are typically stored in /var/spool/cron/crontabs/ directory, though this location may vary depending on your Linux distribution. These files should not be edited directly; instead, use the crontab command to modify them.

When the cron daemon starts, it reads the crontab files and calculates when each command should be executed. Then, it sleeps until the next job needs to be run. At the scheduled time, cron wakes up and executes the specified command, logging the output as configured.

Prerequisites for Using Crontab

Before diving into crontab usage, ensure that the cron service is installed and running on your system. Most Linux distributions include cron by default, but it’s always good to verify.

Checking if Cron is Installed

To check if cron is installed on your system, use one of these commands:

which cron

or

dpkg -l | grep cron  # For Debian-based systems
rpm -q cronie        # For Red Hat-based systems

Installing Cron on Different Linux Distributions

If cron is not installed, you can easily add it using your distribution’s package manager:

For Debian/Ubuntu:

sudo apt-get update
sudo apt-get install cron

For Red Hat/CentOS/Fedora:

sudo yum install cronie

For OpenSUSE:

sudo zypper install cron

Verifying Cron Service Status

After installation, verify that the cron service is running:

systemctl status cron      # For systems using systemd
service cron status        # For systems using System V init

If the service is not running, start it with:

sudo systemctl start cron      # For systems using systemd
sudo service cron start        # For systems using System V init

Ensure the service starts at boot time:

sudo systemctl enable cron     # For systems using systemd
sudo chkconfig cron on         # For systems using System V init

Crontab Command Options and Syntax

The crontab command offers several options for managing your scheduled tasks. Understanding these options is fundamental to effectively working with cron jobs.

Basic Command Structure

The basic syntax for the crontab command is:

crontab [options] [file]

Key Command Options

-e (edit): Opens the current user’s crontab file for editing. If the file doesn’t exist, it creates a new one.

crontab -e

-l (list): Displays the current user’s crontab file.

crontab -l

-r (remove): Deletes the current user’s crontab file.

crontab -r

-i (interactive remove): Prompts for confirmation before removing the crontab file.

crontab -i -r

-u username (user): Specifies which user’s crontab to manipulate (requires root privileges).

sudo crontab -u username -e

System-wide Crontab

For system-wide tasks that need to run regardless of user sessions, you can edit the system crontab:

sudo nano /etc/crontab

This file requires an additional user field to specify which user should run the command.

Understanding Crontab Time Format

The crontab time format is the heart of scheduling in cron. Each crontab entry consists of six fields: the first five define when the command should run, and the sixth is the command itself.

# m h dom mon dow command
# | | |   |   |   |
# | | |   |   |   +-- Command to execute
# | | |   |   +------ Day of week (0-7, where both 0 and 7 represent Sunday)
# | | |   +---------- Month (1-12)
# | | +-------------- Day of month (1-31)
# | +---------------- Hour (0-23)
# +------------------ Minute (0-59)

Special Characters in Crontab

To create flexible schedules, crontab supports several special characters:

Asterisk (*): Represents all possible values for that field. For example, * in the hour field means “every hour”.

Comma (,): Specifies multiple values. For example, 1,3,5 in the day-of-week field means Monday, Wednesday, and Friday.

Hyphen (-): Defines a range of values. For example, 1-5 in the day-of-week field means Monday through Friday.

Forward slash (/): Specifies step values. For example, */15 in the minute field means “every 15 minutes”.

Examples of Time Fields

Let’s examine some examples to illustrate how these fields work together:

Run at 5 AM daily:

0 5 * * * /path/to/command

This runs the command at 5:00 AM every day.

Run twice a day at 6 AM and 6 PM:

0 6,18 * * * /path/to/command

This runs the command at 6:00 AM and 6:00 PM every day.

Run every 15 minutes:

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

This runs the command every 15 minutes throughout the day.

Run every Monday at 7 PM:

0 19 * * mon /path/to/command

This runs the command at 7:00 PM every Monday.

Run on specific months:

* * * feb,jun,oct * /path/to/command

This runs the command every minute during February, June, and October.

Special Crontab Keywords

Crontab provides special keywords (sometimes called “nicknames”) that simplify common scheduling patterns. These keywords make it easier to schedule tasks without having to remember the specific time format.

@reboot: Runs the command once after the system starts.

@reboot /path/to/command

@yearly or @annually: Runs the command once a year at midnight on January 1st (equivalent to 0 0 1 1 *).

@yearly /path/to/command

@monthly: Runs the command once a month at midnight on the first day (equivalent to 0 0 1 * *).

@monthly /path/to/command

@weekly: Runs the command once a week at midnight on Sunday (equivalent to 0 0 * * 0).

@weekly /path/to/command

@daily or @midnight: Runs the command once a day at midnight (equivalent to 0 0 * * *).

@daily /path/to/command

@hourly: Runs the command once an hour at the beginning of the hour (equivalent to 0 * * * *).

@hourly /path/to/command

These keywords are particularly useful for scheduling common tasks like sending greeting messages at the beginning of the year or performing cleanup activities at the start of each month.

Creating Your First Cron Job

Setting up your first cron job is straightforward once you understand the basics. Follow these steps to create and manage your crontab entries.

Step 1: Open the Crontab Editor

Use the following command to open your crontab file in the default editor:

crontab -e

If this is your first time running the command, you might be prompted to select a default text editor. Choose the one you’re most comfortable with, such as nano for beginners or vim for more experienced users.

Step 2: Add a New Cron Job

Add your scheduled command following the crontab time format. For example, to run a script every day at 10 PM:

0 22 * * * /path/to/script.sh

It’s good practice to add comments (lines starting with #) to explain what each job does:

# Backup home directory every night at 10 PM
0 22 * * * /path/to/backup_script.sh

Step 3: Save and Exit

Save the file and exit the editor:

• In nano: Press Ctrl+O to save, then Ctrl+X to exit
• In vim: Press Esc, then type :wq and press Enter

Step 4: Verify Your Crontab

Check that your crontab was saved correctly:

crontab -l

This will display all your current cron jobs.

Common First-time Mistakes

• Incorrect paths: Always use absolute paths for both commands and scripts.
• Missing executable permissions: Ensure your scripts have execute permissions (chmod +x /path/to/script.sh).
• Forgetting the newline at the end: Make sure to end your crontab file with a newline.
• Using improper syntax: Double-check your crontab time format.
• Environment variables: Remember that cron jobs run with a limited environment.

Practical Crontab Examples

Let’s explore some practical examples that demonstrate the versatility of crontab for various system administration tasks.

Running a Command Every Minute

This is useful for monitoring systems or frequently updating logs:

* * * * * /path/to/command

Executing a Command Every 15 Minutes

Perfect for checking services or syncing data:

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

Running a Backup Script at Midnight

Automate your daily backups:

0 0 * * * /usr/local/bin/backup.sh

Scheduling System Updates Weekly

Keep your system updated automatically:

0 3 * * 0 /usr/local/bin/update_system.sh

Creating Monthly Log Rotations

Maintain your log files efficiently:

0 0 1 * * /usr/local/bin/rotate_logs.sh

Running Scripts on Specific Days

Run a script every Monday, Wednesday, and Friday:

0 7 * * 1,3,5 /path/to/script.sh

Scheduling Tasks for Specific Dates

Run a command on March 4 at 7:25 AM:

25 7 4 3 * /home/script/backup.sh

Running Multiple Commands in a Single Cron Job

You can execute multiple commands in sequence using && (runs next command only if previous succeeds) or ; (runs all commands regardless of success):

0 1 * * * /usr/scripts/mysqldump.sh && /usr/scripts/application_backup.sh

Or:

0 1 * * * /usr/scripts/mysqldump.sh; /usr/scripts/application_backup.sh

Using Conditional Execution

Run a command only if another succeeds:

0 8 * * * test -f /path/to/file && /path/to/script.sh

Scheduling Reboot Tasks

Run a command when the system starts:

@reboot /path/to/startup_script.sh

Managing Output and Logs

By default, cron attempts to email the output of your commands to the user who owns the crontab. However, you can redirect this output to better manage your logs.

Redirecting Standard Output and Errors

To capture both standard output and errors in a log file:

0 2 * * * /path/to/script.sh > /var/log/script.log 2>&1

The 2>&1 redirects both standard error (2) and standard output (1) to the log file.

Suppressing All Output

If you don’t need any output, redirect it to /dev/null:

0 2 * * * /path/to/script.sh > /dev/null 2>&1

Setting up the MAILTO Variable

You can specify an email address to receive cron job outputs by setting the MAILTO variable at the top of your crontab:

MAILTO="admin@example.com"
0 2 * * * /path/to/script.sh

If you don’t want any emails, set MAILTO to an empty string:

MAILTO=""
0 2 * * * /path/to/script.sh

Reviewing Cron Logs

Most Linux distributions log cron activity in either /var/log/cron or /var/log/syslog. Check these files if you’re troubleshooting cron job issues:

grep CRON /var/log/syslog

Environment Variables in Crontab

Cron jobs run in a limited environment compared to your interactive shell sessions. This is a common source of confusion when scripts work fine when run manually but fail when executed by cron.

Default Environment

The cron environment typically includes only a few variables like:

• LOGNAME (your username)
• HOME (your home directory)
• PATH (usually limited to /usr/bin:/bin)

Setting Custom Environment Variables

You can set environment variables in your crontab file:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/bash
0 2 * * * /path/to/script.sh

Working Directory Issues

Remember that cron runs with your home directory as the current working directory, regardless of where your script is located. This can cause issues with relative paths. Always use absolute paths or explicitly change directories in your scripts:

0 2 * * * cd /specific/directory && ./script.sh

Best Practices for Crontab Usage

Following these best practices will help you avoid common pitfalls and maintain a robust scheduling system.

Use Absolute Paths

Always use absolute paths for both commands and scripts to avoid path-related issues:

0 2 * * * /usr/local/bin/script.sh

Test Commands Before Adding to Crontab

Always test your commands in a terminal before adding them to crontab. This helps identify issues that might arise from different environment variables or permissions.

Document Your Crontab Entries

Add descriptive comments to each cron job to remind yourself and inform others about what each job does:

# Daily database backup at 1 AM
0 1 * * * /usr/local/bin/backup_database.sh

Monitor Your Cron Jobs

Regularly check that your scheduled tasks are running as expected. Consider implementing monitoring solutions that alert you when jobs fail.

Avoid Resource-Intensive Jobs at Peak Times

Schedule resource-intensive tasks during off-peak hours to avoid impacting system performance when users are active.

Implement Proper Error Handling

Ensure your scripts have proper error handling and reporting. This makes troubleshooting much easier when issues occur.

Use Lock Files for Long-Running Jobs

For long-running tasks, use lock files to prevent multiple instances from running simultaneously:

0 * * * * flock -n /tmp/script.lock /path/to/script.sh

Troubleshooting Common Crontab Issues

Even experienced administrators encounter issues with cron jobs. Here are solutions to common problems.

Diagnosing Why Cron Jobs Aren’t Running

If your cron job isn’t running as expected, check these common issues:

1. Verify cron is running:

systemctl status cron

2. Check your syntax:

crontab -l

3. Look at cron logs:

grep CRON /var/log/syslog

Permission Issues

Ensure your scripts have execute permissions and that the user running the cron job has appropriate permissions for all files and directories involved.

chmod +x /path/to/script.sh

Path-Related Problems

One of the most common issues is path-related problems. The PATH environment variable in cron is limited, so either provide absolute paths or define the PATH in your crontab:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 2 * * * script.sh

Environment Differences

Remember that cron runs in a different environment than your interactive shell. Variables, aliases, and functions that are available in your shell might not be available to cron.

For debugging environment issues, create a cron job that dumps the environment to a file:

* * * * * env > /tmp/cron-env.txt

Missing New Line at End of File

Cron requires a newline at the end of the crontab file. Make sure your file ends with a blank line.

Percentage Signs in Commands

Cron treats % as a newline character in command fields. If you need to use % in your command, escape it with a backslash (\%).

Advanced Crontab Usage

Once you’ve mastered the basics, explore these advanced techniques to make the most of crontab.

Using Crontab with Scripts and Functions

For complex tasks, it’s better to put the logic in a separate script rather than directly in the crontab. This makes maintenance and debugging easier.

Running Jobs as Different Users

System administrators can schedule jobs to run as different users:

sudo crontab -u username -e

Crontab and Containerized Environments

When working with containers, consider whether cron should run inside the container or on the host system. Each approach has pros and cons depending on your specific use case.

Alternative Scheduling Tools

For more advanced scheduling needs, consider these alternatives:

• Anacron: Runs missed jobs when the system was powered off.
• Fcron: Offers more features than cron, including handling system downtime.
• Systemd timers: Modern alternative that integrates with the systemd init system.

Security Considerations

Security should be a priority when setting up cron jobs, especially on production systems.

Limiting Crontab Access

Restrict who can create cron jobs using the /etc/cron.allow and /etc/cron.deny files.

Avoid Privilege Escalation Risks

Be cautious when running scripts as root. Ensure scripts cannot be modified by unauthorized users.

Audit Cron Jobs Regularly

Periodically review all crontab entries to ensure they’re still needed and haven’t been tampered with:

for user in $(cut -f1 -d: /etc/passwd); do echo $user; sudo crontab -u $user -l 2>/dev/null; done

Protect Sensitive Information

Avoid putting passwords or sensitive data directly in crontab entries. Use environment files or secure credential management solutions instead.