RED HAT ENTERPRISE LINUX

Scheduling Future Tasks

Running Commands at Specific Times with at and cron

College-Level Course Module | RHEL System Administration

Welcome to this practical module on scheduling tasks in Red Hat Enterprise Linux. As a system administrator, you'll often need to run commands at specific times - whether it's a one-time task like a system maintenance window, or recurring jobs like daily backups and log rotation. Linux provides two primary tools for this: 'at' for one-time scheduled tasks, and 'cron' for recurring jobs. Both can be used by regular users (with appropriate permissions) to automate their own tasks. In this module, we'll cover both tools in depth, including the crontab syntax that initially seems cryptic but becomes second nature with practice. You'll learn to schedule jobs that run while you sleep, automate repetitive tasks, and manage scheduled jobs effectively. These skills are essential for efficient system administration and are tested on the RHCSA exam.

Learning Objectives

Schedule one-time tasks with at

Run commands at a specific future time using the at command

Schedule recurring tasks with cron

Create crontab entries for jobs that run on a schedule

Understand crontab syntax

Master the five-field time specification format

Manage scheduled jobs

List, modify, and remove scheduled tasks as a regular user

Scheduling Overview

Linux provides tools to run commands automatically at specified times, either once or on a recurring schedule, without user interaction.

at

One-time execution at a specific date/time. Job runs once and is removed.

cron

Recurring execution on a schedule. Jobs repeat until removed.

anacron

Runs missed cron jobs on systems that aren't always on (laptops).

systemd timers

Modern alternative to cron with more features (system-level).

User vs System: Regular users can schedule personal jobs. System-wide jobs in /etc/cron.* require root access.

Linux offers several scheduling mechanisms. The 'at' command handles one-time jobs - you specify when to run something, it runs once, then the job is gone. Perfect for "remind me at 5pm" or "run this backup tonight at midnight." Cron handles recurring jobs - daily backups, weekly reports, hourly checks. Jobs stay scheduled until you remove them. Anacron is a supplement to cron for systems that aren't always running. If your laptop was off when a daily job should have run, anacron catches up when you boot. Systemd timers are the modern alternative, offering more features like randomized delays and better logging, but they're primarily for system services rather than user tasks. For this module, we focus on at and cron, which regular users can use for their own jobs. System-wide scheduling in /etc/cron.d or /etc/cron.daily requires root.

The at Command

The at command schedules a one-time job to run at a specified time. Commands are read from stdin or a file.

# Schedule a job interactively
[student@server ~]$ at 4:00 PM
warning: commands will be executed using /bin/sh
at> echo "Time to go home!" | mail -s "Reminder" student
at> [Ctrl+D to finish]
job 1 at Fri Jan 19 16:00:00 2024

# Schedule from command line
[student@server ~]$ echo "backup.sh" | at midnight

# Schedule from a file
[student@server ~]$ at 9:00 AM tomorrow -f /home/student/scripts/morning.sh

# Check that atd service is running
[student@server ~]$ systemctl status atd

Requirement: The atd service must be running. Check with systemctl status atd.

at Time Specifications

at 4:00 PM

Today at 4:00 PM (or tomorrow if past)

at 16:00

24-hour format, same as 4:00 PM

at midnight

12:00 AM tonight

at noon

12:00 PM today

at tomorrow

Same time tomorrow

at now + 2 hours

2 hours from now

at now + 30 minutes

30 minutes from now

at 9:00 AM Jan 20

Specific date and time

at 9:00 AM 1/20/24

Date in MM/DD/YY format

at teatime

4:00 PM (a fun alias!)

# Relative time examples
[student@server ~]$ at now + 1 week
[student@server ~]$ at 5 PM + 3 days
[student@server ~]$ at 10:00 AM next Monday

Managing at Jobs

# List pending at jobs
[student@server ~]$ atq
1       Fri Jan 19 16:00:00 2024 a student
2       Sat Jan 20 00:00:00 2024 a student
3       Mon Jan 22 09:00:00 2024 a student

# View contents of a specific job
[student@server ~]$ at -c 1
#!/bin/sh
# atrun uid=1000 gid=1000
...
cd /home/student || { ... }
echo "Time to go home!" | mail -s "Reminder" student

# Remove a job by number
[student@server ~]$ atrm 2
[student@server ~]$ atq
1       Fri Jan 19 16:00:00 2024 a student
3       Mon Jan 22 09:00:00 2024 a student

# Alternative: at -r (same as atrm)
[student@server ~]$ at -r 3

Job Numbers: Each at job gets a unique number. Use this number with at -c to view or atrm to remove.

at Access Control

/etc/at.allow

If exists, only users listed can use at. One username per line.

/etc/at.deny

If at.allow doesn't exist, users listed here are denied. Empty = all allowed.

# Check if you can use at
[student@server ~]$ at now + 1 minute
warning: commands will be executed using /bin/sh
at>    # If you get a prompt, you're allowed

# If denied:
You do not have permission to use at.

# View access files (as root)
[root@server ~]# cat /etc/at.deny
(empty by default - all users allowed)

Default Behavior: By default, /etc/at.deny exists but is empty, allowing all users to use at. If /etc/at.allow exists, it takes precedence.

Introduction to cron

cron is a daemon that executes scheduled commands at recurring intervals. Jobs are defined in crontab (cron table) files.

User Crontabs

Personal schedules managed with crontab -e. Each user has their own.

System Crontabs

/etc/crontab and /etc/cron.d/* for system-wide jobs (root only).

Cron Directories

/etc/cron.hourly, daily, weekly, monthly for simple scheduling.

crond Service

The daemon that reads crontabs and executes jobs on schedule.

# Verify cron daemon is running
[student@server ~]$ systemctl status crond
● crond.service - Command Scheduler
     Loaded: loaded
     Active: active (running)

Cron is the traditional Unix job scheduler. The crond daemon runs continuously, checking crontabs every minute and executing any jobs whose time has come. There are several types of cron configuration. User crontabs are personal schedules - each user can have one, managed with the crontab command. These are stored in /var/spool/cron/. System crontabs are in /etc/crontab and /etc/cron.d/ directory. These require root to edit and include a username field specifying who runs the job. The cron directories (/etc/cron.hourly, daily, weekly, monthly) offer simple scheduling - just drop an executable script in the appropriate directory. These are managed by anacron on modern systems. For this module, we focus on user crontabs, which any user can manage for their own jobs. The crond service must be running - check with systemctl status crond.

crontab Commands

# Edit your crontab (opens in default editor)
[student@server ~]$ crontab -e

# List your crontab entries
[student@server ~]$ crontab -l
30 8 * * 1-5 /home/student/scripts/morning-report.sh
0 0 * * * /home/student/scripts/daily-backup.sh

# Remove your entire crontab (dangerous!)
[student@server ~]$ crontab -r

# Remove with confirmation prompt
[student@server ~]$ crontab -ri
crontab: really delete student's crontab? y

# Root can manage other users' crontabs
[root@server ~]# crontab -l -u student
[root@server ~]# crontab -e -u student

⚠ Warning: crontab -r removes ALL your cron jobs without confirmation! Use crontab -ri or just crontab -e to delete specific lines.

The crontab command manages your personal cron schedule. crontab -e opens your crontab in your default editor (usually vi). When you save and exit, the new crontab is installed. If there are syntax errors, cron will tell you. crontab -l lists your current crontab entries. This is useful for checking what's scheduled without risking accidental changes. crontab -r removes your ENTIRE crontab - all jobs gone with one command and no confirmation. This is dangerous and easy to do accidentally. Use crontab -ri instead, which prompts for confirmation, or use crontab -e and delete specific lines. Root can use -u username to manage any user's crontab. This is useful for troubleshooting or managing cron jobs for service accounts. The editor used by crontab -e is determined by the VISUAL or EDITOR environment variables. To use nano instead of vi: export EDITOR=nano before running crontab -e.

Crontab Syntax

Minute
(0-59)

Hour
(0-23)

Day of Month
(1-31)

Month
(1-12)

1-5

Day of Week
(0-7)

/path/to/script.sh

Command

# Format: MIN HOUR DOM MON DOW COMMAND

30 8 * * 1-5 /home/student/scripts/morning-report.sh
#  │ │ │ │ └── Day of week: 1-5 (Mon-Fri)
#  │ │ │ └──── Month: * (every month)
#  │ │ └────── Day of month: * (every day)
#  │ └──────── Hour: 8 (8 AM)
#  └────────── Minute: 30

# This job runs at 8:30 AM, Monday through Friday

The crontab syntax uses five time fields followed by the command to run. This is the heart of cron scheduling. Field 1 (Minute): 0-59. When in the hour to run. Field 2 (Hour): 0-23. Which hour (24-hour format). Field 3 (Day of Month): 1-31. Which day of the month. Field 4 (Month): 1-12 or names (jan, feb, etc.). Field 5 (Day of Week): 0-7 where both 0 and 7 mean Sunday, or names (sun, mon, etc.). Field 6: The command to execute. An asterisk (*) means "every" - every minute, every hour, every day, etc. The example "30 8 * * 1-5" means: minute 30, hour 8, every day of month, every month, days 1-5 (Monday through Friday). So it runs at 8:30 AM on weekdays. Note that day of month and day of week interact specially - if both are specified (not *), the job runs when EITHER matches, not both.

Crontab Special Characters

Character	Meaning	Example
*	Every value	`* * * * *` = every minute
,	List of values	`0,15,30,45` = these minutes
-	Range of values	`9-17` = hours 9 through 17
/	Step values	`*/15` = every 15 units

# Every 15 minutes
*/15 * * * * /path/to/script.sh

# At minutes 0, 15, 30, 45 (same as above)
0,15,30,45 * * * * /path/to/script.sh

# Every weekday at 9 AM
0 9 * * 1-5 /path/to/script.sh

# First day of each month at midnight
0 0 1 * * /path/to/script.sh

# Every 2 hours on weekends
0 */2 * * 0,6 /path/to/script.sh

Crontab Examples

# Every minute (good for testing, remove after!)
* * * * * echo "test" >> /tmp/crontest.log

# Daily at 2:30 AM
30 2 * * * /home/student/scripts/daily-backup.sh

# Every Monday at 9 AM
0 9 * * 1 /home/student/scripts/weekly-report.sh

# First of each month at midnight
0 0 1 * * /home/student/scripts/monthly-cleanup.sh

# Every 5 minutes during business hours on weekdays
*/5 9-17 * * 1-5 /home/student/scripts/check-status.sh

# Twice daily at 8 AM and 8 PM
0 8,20 * * * /home/student/scripts/sync-data.sh

# 15th and last day of month (approximated with 28th)
0 0 15,28 * * /home/student/scripts/bimonthly.sh

Testing Tip: Use * * * * * to run every minute while testing, then change to the real schedule once verified.

Let's look at practical examples that cover common scheduling needs. Every minute runs a job 60 times per hour - only use this for testing, then remove or adjust. Daily jobs typically run at night during low-usage hours - 2:30 AM avoids the midnight rush when many cron jobs run. Weekly jobs on Monday morning catch up from the weekend. Monthly jobs on the 1st work well for reporting periods. Business hours monitoring with "*/5 9-17 * * 1-5" runs every 5 minutes between 9 AM and 5 PM on weekdays - great for status checks. Twice daily with "0 8,20 * * *" uses a list in the hour field. Bimonthly is tricky since months have different lengths - using 15 and 28 is an approximation. For exact "last day of month," you'd need a script that checks the date. When developing cron jobs, always test with a simple command like echoing to a log file before using your real script.

Cron Special Strings

Instead of five fields, you can use these shortcuts for common schedules:

String	Meaning	Equivalent
@reboot	Run once at startup	N/A
@yearly / @annually	Once a year	0 0 1 1 *
@monthly	Once a month	0 0 1 * *
@weekly	Once a week	0 0 * * 0
@daily / @midnight	Once a day	0 0 * * *
@hourly	Once an hour	0 * * * *

# Start a process at system boot
@reboot /home/student/scripts/start-app.sh

# Daily backup at midnight
@daily /home/student/scripts/backup.sh

# Weekly cleanup on Sunday at midnight
@weekly /home/student/scripts/cleanup.sh

Cron Environment

Important: Cron jobs run with a minimal environment, not your normal login environment! Many commands may not work as expected.

# Cron's default PATH is limited:
PATH=/usr/bin:/bin

# Set your own PATH and variables in crontab:
PATH=/usr/local/bin:/usr/bin:/bin:/home/student/bin
MAILTO=student@example.com
HOME=/home/student

# Then your jobs:
30 8 * * * morning-report.sh     # Now finds scripts in your bin

# Or use full paths in commands:
30 8 * * * /home/student/scripts/morning-report.sh

# Or source your profile in the script:
#!/bin/bash
source ~/.bash_profile
# rest of script...

MAILTO: Set MAILTO=your@email.com to receive job output. Set MAILTO="" to disable mail.

One of the most common cron problems is the limited environment. When you run commands interactively, you have your full PATH, aliases, and environment variables. Cron jobs run with a minimal environment - usually just PATH=/usr/bin:/bin. This means: commands that work interactively may fail in cron ("command not found"), environment variables you depend on may not exist, and relative paths might not resolve correctly. Solutions: Set PATH and other variables at the top of your crontab - these apply to all jobs below. Use absolute paths for all commands in your cron jobs. Have your scripts source your profile if they need your environment. The MAILTO variable controls where cron output goes. By default, output is mailed to the user. Set MAILTO to a different address, or MAILTO="" to discard output. Better practice: have your scripts log output themselves and redirect stdout/stderr in the crontab entry.

Cron Output and Logging

# By default, all output is mailed to the user
# Redirect output to a log file instead:
30 2 * * * /path/to/backup.sh >> /home/student/logs/backup.log 2>&1

# Discard all output:
*/5 * * * * /path/to/check.sh > /dev/null 2>&1

# Log with timestamp:
0 * * * * echo "$(date): Starting hourly job" >> ~/logs/cron.log

# In your crontab, disable mail globally:
MAILTO=""
* * * * * /path/to/job.sh

# Check system cron log for execution records:
[student@server ~]$ grep CRON /var/log/cron
Jan 19 08:30:01 server CRON[1234]: (student) CMD (/home/student/scripts/job.sh)

Best Practice: Always redirect output to log files. Include timestamps. Don't rely on cron mail for production jobs.

Managing cron output is crucial for debugging and monitoring. By default, any output from a cron job (stdout and stderr) is collected and mailed to the user. On systems without local mail delivery, this output is often lost. Best practice is explicit redirection. The pattern ">> logfile 2>&1" appends stdout to the log and redirects stderr to stdout (so both go to the log). Using >> appends rather than overwriting, preserving history. To discard output completely, redirect to /dev/null. But be careful - this hides errors too. Only do this for jobs you're confident about. For debugging, add timestamps to your output. The system logs cron executions in /var/log/cron (or through journalctl). This shows that cron ran your job, but not whether it succeeded or what output it produced - that's what your own logging captures.

Cron Access Control

/etc/cron.allow

If exists, only listed users can use cron.

/etc/cron.deny

If cron.allow doesn't exist, listed users are denied.

# Check if you can use cron
[student@server ~]$ crontab -e
# If you can edit, you're allowed

# If denied:
You (student) are not allowed to use this program (crontab)

# View access files (as root)
[root@server ~]# cat /etc/cron.allow
root
admin
student

# Default on RHEL: /etc/cron.deny exists but is empty
# This means all users can use cron

System Cron Directories

# Drop-in directories for simple scheduling (root only)
/etc/cron.hourly/     # Scripts run every hour
/etc/cron.daily/      # Scripts run daily
/etc/cron.weekly/     # Scripts run weekly
/etc/cron.monthly/    # Scripts run monthly

# List daily cron scripts
[student@server ~]$ ls /etc/cron.daily/
logrotate  man-db  mlocate

# System crontab (different format - has username field)
[student@server ~]$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# MIN HOUR DOM MON DOW USER  COMMAND
  *   *    *   *   *  root  /path/to/script.sh

# Additional system cron jobs
/etc/cron.d/         # Drop-in crontab files

Note: These system directories require root to modify. For user jobs, use crontab -e instead.

Beyond user crontabs, there are system-level cron facilities. The cron directories (hourly, daily, weekly, monthly) are simple: drop an executable script in the directory, and it runs on that schedule. No crontab syntax needed. Scripts here are typically run by anacron, which ensures jobs run even if the system was off at the scheduled time. The /etc/crontab file is the system crontab. It has an additional field - the username - specifying who runs each job. Only root can edit this. /etc/cron.d/ contains additional crontab-format files, each following the system format with the username field. Packages often install their cron jobs here. These system facilities are important to know about but are typically managed by root or packages. Regular users should use "crontab -e" for their personal jobs.

Practical Example: Backup

# Create a backup script
[student@server ~]$ vim ~/scripts/backup-home.sh

#!/bin/bash
# backup-home.sh - Backup home directory
BACKUP_DIR="/home/student/backups"
DATE=$(date +%Y%m%d)
LOG="$BACKUP_DIR/backup.log"

echo "$(date): Starting backup" >> "$LOG"

tar -czf "$BACKUP_DIR/home-$DATE.tar.gz" \
    --exclude="$BACKUP_DIR" \
    /home/student 2>> "$LOG"

if [ $? -eq 0 ]; then
    echo "$(date): Backup completed successfully" >> "$LOG"
else
    echo "$(date): Backup FAILED" >> "$LOG"
fi

# Keep only last 7 backups
ls -t "$BACKUP_DIR"/home-*.tar.gz | tail -n +8 | xargs rm -f 2>/dev/null

# Schedule daily at 2 AM
[student@server ~]$ crontab -e
0 2 * * * /home/student/scripts/backup-home.sh

Troubleshooting

# Check if cron/at daemons are running
[student@server ~]$ systemctl status crond atd

# Check cron log for execution
[student@server ~]$ grep CRON /var/log/cron
[student@server ~]$ journalctl -u crond --since "1 hour ago"

# Test your script manually first!
[student@server ~]$ /home/student/scripts/myscript.sh

# Test with cron's environment
[student@server ~]$ env -i /bin/sh -c '/home/student/scripts/myscript.sh'

# Check file permissions
[student@server ~]$ ls -l /home/student/scripts/myscript.sh
-rwxr-xr-x. 1 student student 256 Jan 19 10:00 myscript.sh

# Verify crontab syntax
[student@server ~]$ crontab -l

Common Problems: Script not executable, wrong PATH, missing dependencies, permission denied, output lost because no redirection.

When scheduled jobs don't work, follow this troubleshooting approach. First, verify the daemons are running. No crond means no cron jobs execute. Check the cron log to see if cron attempted to run your job. "No entry in log" means cron didn't try - check your crontab syntax and timing. "Entry in log" but no result means the job started but something went wrong. Always test scripts manually before scheduling. If it doesn't work from the command line, it won't work in cron. Test with a minimal environment using "env -i" to simulate cron's limited environment. This often reveals PATH and dependency issues. Check file permissions - scripts must be executable (chmod +x). Check that all paths in the script are absolute or that PATH is set correctly. The most common issues: script isn't executable, commands not found due to PATH, output lost because of no redirection hiding errors, and wrong time specification.

Best Practices

✓ Do

Use absolute paths in scripts and crontab
Set PATH and MAILTO in crontab
Redirect output to log files
Include timestamps in logs
Test scripts manually first
Use comments to document jobs
Keep scripts in a dedicated directory
Make scripts executable (chmod +x)

✗ Don't

Use relative paths
Assume your environment is available
Ignore output (redirect to /dev/null blindly)
Forget to make scripts executable
Schedule intensive jobs during peak hours
Use crontab -r casually
Leave test entries (* * * * *) running
Assume jobs ran - verify!

# Well-documented crontab example:
PATH=/usr/local/bin:/usr/bin:/bin:/home/student/bin
MAILTO=""

# Morning report - weekdays at 8:30 AM
30 8 * * 1-5 /home/student/scripts/morning-report.sh >> ~/logs/report.log 2>&1

# Daily backup - 2 AM
0 2 * * * /home/student/scripts/backup-home.sh

Following best practices prevents the most common scheduling problems. Always use absolute paths - both in your crontab entries and within scripts. This eliminates PATH-related failures. Set PATH at the top of your crontab if you want to use short command names. Set MAILTO to control where output goes - either a valid email or empty to disable. Redirect output in your cron entries. Logging to files gives you a record of what happened. Timestamps help you correlate events. Test everything manually before scheduling. Comment your crontab entries - you'll thank yourself when reviewing months later. Don't blindly redirect to /dev/null - you lose error information. Don't assume cron's environment matches yours. Don't forget chmod +x on scripts. Schedule intensive jobs during off-hours to avoid impacting users. Never leave every-minute test entries running - they fill logs and waste resources.

Key Takeaways

at: One-time jobs with flexible time specs. at 4pm tomorrow, manage with atq/atrm

crontab: Edit with -e, list with -l, remove with -r. Never use -r carelessly!

Cron syntax: MIN HOUR DOM MON DOW CMD. Use * for "every", ranges with -, lists with ,, steps with /

Environment: Set PATH/MAILTO in crontab. Use absolute paths. Redirect output to logs.

Next: Managing Temporary Files