Scheduled background tasks with cron

Table of contents

If you're new to Linux, you might have heard about "cron" and wondered what it is. Essentially, cron is a service running locally that executes recurring background tasks at specific schedules. It is a vital tool to keep servers and long-running systems healthy by running maintenance tasks automatically.

How cron works

Cron is a time-based job scheduler in Unix-like operating systems, including Linux. Think of it as a personal assistant that runs tasks (called "cron jobs") at specific times or intervals. Whether you want to back up your files daily, clean up temporary files weekly, or send yourself reminders, cron can handle it all.

Cron uses a special file called the "crontab" (short for "cron table") to manage scheduled tasks. Each user on a Linux system can have their own crontab file, and there's also a system-wide crontab for tasks that affect all users.

The Crontab Syntax

Crontab files have a simple syntax that specifies when a task should run and what command should be executed. Each line in a crontab file follows this structure:

System-Wide Directories for Cron Jobs

In addition to user-specific crontabs, Linux has several directories where system-wide cron jobs can be placed. These jobs run as the root user, which means they have complete access to the system. Here are the common directories:

  • /etc/cron.daily: Scripts placed in this directory run once a day.

  • /etc/cron.weekly: Scripts placed here run once a week.

  • /etc/cron.monthly: Scripts placed here run once a month.

  • /etc/cron.hourly: Scripts placed here run once an hour.

Simply place your script in the appropriate directory, and it will be executed at the specified interval.

Global cron jobs

These files allow for more complex scheduling and are also used for system-wide tasks. The syntax here includes a username field, which specifies the user under which the job should run. Here's the structure for these files:

For example, to run a backup script as the user backupuser every day at 2 AM, you would add the following line to /etc/crontab or a file in /etc/cron.d:

0 2 * * * backupuser /path/to/

Managing User-Specific Cron Jobs

Each user can manage their own cron jobs without needing root permissions. To edit your crontab, use the crontab command:

  • Edit your crontab: crontab -e

  • List your cron jobs: crontab -l

  • Remove your crontab: crontab -r

Using the crontab command ensures that the syntax is correct when you save your crontab file. This prevents common errors that can occur if you manually edit the crontab file.

User-specific crontabs do not include the username field in their syntax. Here's an example of a user-specific crontab entry:

0 2 * * * /home/yourusername/

Logging cron job output

Proper logging of your cron jobs can help you monitor their execution and quickly identify any issues.

To log both the standard output (stdout) and standard error (stderr) of your cron jobs, you need to redirect them to a log file. The following example shows how to do this:

0 2 * * * /home/yourusername/ >> /home/yourusername/backup.log 2>&1

 In this command, >> /home/yourusername/backup.log appends the standard output to backup.log, while 2>&1 redirects the standard error to the same location as the standard output.

To include timestamps in your log file, so you know exactly when each job ran, you can modify your script to include date and time information. Here's an updated version of the backup script with timestamp logging:

  echo "[$(date +'%Y-%m-%d %H:%M:%S')] Starting backup" >> /home/yourusername/backup.log
  tar -czf /home/yourusername/backup-$(date +\%Y\%m\%d).tar.gz /home/yourusername/importantfiles >> /home/yourusername/backup.log 2>&1
  echo "[$(date +'%Y-%m-%d %H:%M:%S')] Backup completed" >> /home/yourusername/backup.log

With this script, each entry in the log file will have a timestamp indicating when the backup started and completed.

For even more robust setups, this log file should be trimmed and rotated regularly (for example using logrotate), and failed cronjobs should trigger a notification mechanism, like an email or a webhook to the company chat server.

More articles

Setting up an nginx load balancer

Distributing requests to multiple servers

Simplifying terminal operations with python modules

Saving time with python builtin modules

A complete guide to running windows software on linux

Making windows programs behave like they were written for linux

Working with tar archives

...and tar.gz, tar.bz2 and tar.xz

Understanding the linux tee command

Copying stdin to multiple outputs

Protecting linux servers from malware with ClamAV and rkhunter

Finding malicious files the open source way