Cron jobs

What is cron?

cron is a job scheduler in Linux and Unix systems that executes tasks at scheduled times. It allows users to automatically run scripts, commands, or software at specified intervals. cron is ideal for recurring tasks, such as data backups and system updates.

How cron works

cron uses crontab (cron table) files. These configuration files contain commands and their corresponding execution schedules. Each user can have their own crontab file in their home directory, and there is also a system-level crontab file for administrator-managed tasks.

The cron daemon periodically checks these crontab files, parses their schedules and commands, and executes them at the scheduled times.

Cron components

1. Cron daemon: A background process that checks, schedules, and executes the jobs specified in crontab files.

2. Crontab files:

   • User-level crontab: Each user can edit their own scheduled jobs by running the crontab -e command. These jobs apply only to the current user.

   • System-level crontab: Located in /etc/crontab, this file is typically managed by a system administrator for system-level tasks.

3. Crontab syntax: Each line in a crontab file consists of six fields: minute, hour, day-of-month, month, day-of-week, and the command to execute.

Cron expression

The following example shows a simple crontab file entry:

# .---------------- minute
# |  .------------- hour
# |  |  .---------- day of month 
# |  |  |  .------- month 
# |  |  |  |  .---- day of week (Sunday=0 or 7)
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
  30 04 *  *  *   root     /path/to/daily_backup.sh

This cron job is configured to run the daily_backup.sh script as the root user at 4:30 AM every day.

Considerations

• Ensure the source file path (/path/to/original/file.txt) and the backup path (/path/to/backup/file_backup.txt) are correct.

• Verify that the destination directory exists. If not, create it or add a directory creation command to the cron job.

• Ensure the user running the cron job has read permissions on the source file and write permissions on the destination directory.

• Periodically check the backup files and logs to verify that the cron job is running correctly and that the backup files are valid.

Cron job timeouts

• Solutions:

  • Optimize the script: Refine the script's logic to reduce its execution time.

  • Split the job: If the job can be split, break it into multiple smaller jobs.

  • Use a timeout: Use the timeout utility in your cron job command to limit the script's maximum execution time. For example, 0 5 * * * timeout 300 /path/to/script.sh limits the script's execution to 300 seconds.

Simple test command

Before configuring a complex cron job, use a simple test command to verify that it triggers correctly. For example, set up a job to append the current date and time to a file every minute:

* * * * * date >> /path/to/date_output.txt

After a few minutes, check the date_output.txt file to verify that a new timestamp is appended each minute.

Redirect output for testing

To test a cron job, add output redirection to the command. This directs the standard output (stdout) and standard error (stderr) to a log file, so you can check if the script executed and review its output.

30 4 * * * /path/to/your-script.sh > /path/to/logfile.log 2>&1

Check the /path/to/logfile.log file to review the script's output and any errors.

Cron job execution frequency

• Configuration recommendations:

  • Avoid excessive frequency: Setting an overly frequent execution schedule can harm system performance.

  • Configure as needed: Simple, routine jobs like backups may only need to run once a day, while monitoring jobs might need to run every hour or more frequently.

  • Consider system load: Schedule resource-intensive jobs to run during periods of low system load.

Other troubleshooting tips

• Output redirection: Redirect the output and errors of your cron job to a log file for easier troubleshooting. For example: 30 4 * * * /path/to/job.sh > /path/to/job.log 2>&1

• Email notifications: If a cron job generates output or an error, the cron daemon sends a notification email. Ensure your system mail service is configured correctly, or explicitly configure email delivery within the cron job.

• Path issues: Absolute paths are generally more reliable than relative paths. Use absolute paths in your cron jobs whenever possible.

• Editing and viewing cron jobs: Use crontab -e to edit cron jobs and crontab -l to view all cron jobs for the current user. This helps ensure your jobs are configured correctly.

Cron job not executing on schedule

• Causes and solutions:

  • Incorrect cron expression: Check the format of the cron expression. Ensure the time and date fields are correct.

  • Insufficient script permissions: Ensure the script has the necessary execution permissions. Use chmod +x /path/to/script.sh to grant them.

  • Environment issues: cron jobs run in a minimal environment and may not load your user's full shell configuration. Use absolute paths for commands in your script, or explicitly set required environment variables within the script itself.

  • Log check: Check the cron log, which is typically located at /var/log/cron or /var/log/syslog (depending on the system), for trigger information and potential errors. Also, check any output redirection logs you have configured.

View all cron jobs for a user

The crontab -l command lists the cron jobs for the current user. cron is a time-based job scheduler in Unix-like operating systems that automatically runs scheduled commands or scripts.

• Notes:

  • Only the cron jobs for the current user are listed. To view the cron jobs of other users, you typically need root privileges or appropriate system permissions.

  • If no cron jobs are configured for the user, the crontab -l command may return no output or display a message that the crontab is empty.

List cron jobs in a crontab

To list the cron jobs for the current user, run the command crontab -l. This command displays all cron jobs defined in the current user's crontab file.

• Notes:

  • Permissions: Regular users can only view and edit their own cron jobs. The root user or users with appropriate permissions can view and edit the cron jobs of all users.

  • Environment: Commands executed by cron run in a minimal environment, where many user-specific environment variables may not be loaded by default. Therefore, use absolute paths for commands and files.

Delete a specific cron job

1. Open the crontab editor: Run the crontab -e command. This opens the current user's crontab file in the default text editor, such as vi or nano.

2. Delete the specific job: In the editor, find the line for the job you want to delete and remove it. In vi or vim, you can move the cursor to the line and press dd. In nano, move to the line and press Ctrl+K to cut it.

3. Save and exit:

   • In vi or vim, type :wq and press Enter to save your changes and exit.

   • In nano, press Ctrl+X, then Y to confirm you want to save, and finally press Enter to exit.

4. To delete all cron jobs for the current user, use the following command.

crontab -r

• Notes:

  • Backup: Before editing or deleting cron jobs, it is a good practice to back up your crontab. You can save your current jobs to a file using crontab -l > crontab_backup.txt.

  • Caution: Deleting or modifying cron jobs can affect system operations or application functionality. Ensure you understand the purpose of a job before modifying it.

Resolve "not allowed to use crontab" error

1. Connect to the ECS instance as the root user.

   For more information, see Log on to a Linux instance using Workbench.

2. Run the following commands to check for the existence of the cron.allow or cron.deny files:

   find /etc/cron.allow
   find /etc/cron.deny

   A user's permission to run the crontab command depends on the /etc/cron.allow and /etc/cron.deny files, as detailed below.

   Cron.allow exists

   Cron.deny exists

   Authorized crontab users

   Cron.allow exists	Cron.deny exists	Authorized crontab users
   No	No	Only the root user can use the crontab command.
   Yes	No	Only users listed in the cron.allow file can use the crontab command.
   No	Yes	All users not listed in the cron.deny file can use the crontab command. Note If the cron.deny file is empty, all users can use the crontab command.
   Yes	Yes	Only users listed in the cron.allow file can use the crontab command. Note The cron.allow file takes precedence over the cron.deny file. In this case, the cron.deny file has no effect.

3. Based on your requirements, edit the cron.allow or cron.deny file.

   • If the cron.allow file does not exist and the non-root user's username is in the cron.deny file, remove the username from cron.deny and save the file.

   • If the cron.allow file exists, add the non-root user's username to the cron.allow file and save the file.

4. Restart the cron service for the changes to take effect:

   systemctl restart crond.service

5. Switch to the non-root user and run the crontab command again to verify that it can be executed successfully.

Fix "errors in crontab file" error

To resolve this issue, log on to the instance to correct the crontab file format or perform cloud disk resizing if the disk is full.

1. Connect to your ECS instance.

   For more information, see Connection methods for ECS instances.

2. Check whether the cron job format in the crontab file is correct.

   • If the format is correct, proceed to step 3.

   • If the format is incorrect, correct it as follows:

     

3. Run the following command to check disk usage:

   df -h

   The system displays information similar to the following. For example, Use% shows the usage of the /dev/xvda1 partition.

   If disk usage is close to 100%, the disk space is insufficient. We recommend resizing the cloud disk. For more information, see Cloud disk resizing overview.

   [root@ ~]# df -h
   Filesystem Size Used Avail Use% Mounted on
   /dev/xvda1 20G 2.7G 17G 15% /
   tmpfs 498M 0 498M 0% /dev/shm