RED HAT ENTERPRISE LINUX

System Scheduling

Scheduling Recurring Tasks for Daemons and OS Functions

College-Level Course Module | RHEL System Administration

Welcome to this module on system-level task scheduling in Red Hat Enterprise Linux. While the previous module covered user-level scheduling with at and crontab, this module focuses on scheduling tasks that support system operations - the recurring jobs that keep your operating system healthy and daemons running smoothly. We'll explore three key mechanisms: systemd timers (the modern approach that integrates with systemd's service management), system crontabs and cron directories (the traditional approach still widely used), and anacron (which ensures jobs run even on systems that aren't always powered on). You'll learn when to use each approach, how to configure them, and best practices for system maintenance tasks. These are administrator-level operations requiring root access, and they're essential for maintaining healthy RHEL systems.

Learning Objectives

Understand systemd timers

Create and manage timer units for scheduled service activation

Configure system cron jobs

Use /etc/crontab, /etc/cron.d/, and cron directories for system tasks

Use anacron for resilient scheduling

Ensure jobs run on systems that aren't continuously powered

Manage temporary files with systemd-tmpfiles

Configure automatic cleanup of temporary and transient files

We have four main learning objectives for system-level scheduling. First, we'll master systemd timers - the modern replacement for cron that integrates with systemd's service management, offering features like dependencies, resource control, and better logging. Second, we'll configure system cron jobs using the system crontab and cron directories. These traditional mechanisms are still heavily used and important to understand. Third, we'll explore anacron, which solves the problem of missed jobs on systems that aren't always running - essential for laptops, desktops, and virtual machines that get shut down. Fourth, we'll learn about systemd-tmpfiles, which handles automatic cleanup of temporary files - a critical system maintenance task. All of these require root access and are focused on system-level operations.

System Scheduling Overview

System scheduling runs recurring tasks that maintain OS health: log rotation, temporary file cleanup, security updates, database maintenance, and service health checks.

systemd Timers

Modern approach. Timer unit activates a service unit on schedule. Full systemd integration.

System Cron

/etc/crontab and /etc/cron.d/. Traditional scheduling with username field.

anacron

Catches up on missed jobs. Used for daily/weekly/monthly system tasks.

systemd-tmpfiles

Manages temporary files. Creates, cleans, and removes files/directories.

Root Required: System scheduling mechanisms require administrator privileges to configure.

System scheduling differs from user scheduling in scope and purpose. These are tasks that maintain the operating system itself, not individual user tasks. Systemd timers are the modern approach in RHEL. A timer unit triggers a service unit on a schedule. This gives you all of systemd's benefits: dependency management, resource controls, logging through journald, and consistent management with systemctl. System cron through /etc/crontab and /etc/cron.d/ is the traditional approach. It includes a username field to specify which user runs each job. Many existing systems and packages still use this. Anacron ensures daily, weekly, and monthly jobs run even if the system was off at the scheduled time. It's crucial for systems that aren't servers running 24/7. Systemd-tmpfiles handles temporary file management - creating directories at boot, cleaning up old files, maintaining proper permissions. It's separate from scheduling but related to system maintenance. All of these require root access to configure.

systemd Timers Introduction

A systemd timer is a unit that activates another unit (usually a service) based on time. Timers are the systemd replacement for cron jobs.

# List all timers
[root@server ~]# systemctl list-timers
NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES
Sun 2024-01-21 00:00:00 EST 5h 30min left Sat 2024-01-20 00:00:00 EST 18h ago      logrotate.timer              logrotate.service
Sun 2024-01-21 00:00:00 EST 5h 30min left Sat 2024-01-20 00:00:00 EST 18h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2024-01-22 00:00:00 EST 1 day left    Mon 2024-01-15 00:00:00 EST 5 days ago   fstrim.timer                 fstrim.service

# Include inactive timers
[root@server ~]# systemctl list-timers --all

# Show timer status
[root@server ~]# systemctl status logrotate.timer
● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled)
     Active: active (waiting)

Systemd timers are unit files that trigger other units on a schedule. They're the modern alternative to cron, offering better integration with the system. The systemctl list-timers command shows active timers, when they'll next run, when they last ran, and what service they activate. This gives you visibility into scheduled system tasks. Common system timers include: logrotate.timer for rotating log files, systemd-tmpfiles-clean.timer for cleaning temporary files, fstrim.timer for SSD maintenance, and dnf-makecache.timer for package cache updates. Each timer has a corresponding service that does the actual work. The timer just controls WHEN the service runs. Timers can be enabled/disabled and started/stopped like any systemd unit. When enabled, they start automatically at boot.

Timer Unit Structure

# /etc/systemd/system/backup.timer

[Unit]
Description=Daily Backup Timer

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/backup.service

[Unit]
Description=System Backup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# Enable and start the timer
[root@server ~]# systemctl daemon-reload
[root@server ~]# systemctl enable --now backup.timer

# Verify it's scheduled
[root@server ~]# systemctl list-timers backup.timer

A systemd timer consists of two files: a .timer unit that defines the schedule, and a .service unit that defines what to run. The timer unit has three sections. [Unit] contains metadata like Description. [Timer] contains the schedule - OnCalendar for calendar-based times, or monotonic options like OnBootSec. Persistent=true means if a scheduled run was missed (system was off), run it when the system starts. [Install] specifies WantedBy=timers.target so the timer starts at boot when enabled. The service unit is typically Type=oneshot for scheduled tasks - it runs once and exits, rather than staying running like a daemon. ExecStart specifies the command or script to run. By convention, the timer and service share the same base name: backup.timer activates backup.service automatically. After creating the files, run daemon-reload to read them, then enable and start the timer.

OnCalendar Syntax

The OnCalendar directive uses a flexible calendar event syntax: DayOfWeek Year-Month-Day Hour:Minute:Second

*-*-* 02:00:00

Every day at 2:00 AM

Mon *-*-* 09:00:00

Every Monday at 9:00 AM

*-*-01 00:00:00

First of every month at midnight

*-01-01 00:00:00

January 1st each year

Mon..Fri *-*-* 08:00:00

Weekdays at 8:00 AM

*-*-* *:00,30:00

Every 30 minutes

daily

Shorthand for *-*-* 00:00:00

weekly

Shorthand for Mon *-*-* 00:00:00

# Test calendar expressions with systemd-analyze
[root@server ~]# systemd-analyze calendar "Mon..Fri *-*-* 09:00:00"
  Original form: Mon..Fri *-*-* 09:00:00
Normalized form: Mon..Fri *-*-* 09:00:00
    Next elapse: Mon 2024-01-22 09:00:00 EST
       (in UTC): Mon 2024-01-22 14:00:00 UTC
       From now: 1 day 3h left

The OnCalendar syntax is powerful and more readable than cron's five fields. The format is "DayOfWeek Year-Month-Day Hour:Minute:Second" where any component can use wildcards (*), ranges (..), or lists (,). Examples: "*-*-* 02:00:00" means every day at 2 AM. "Mon *-*-* 09:00:00" means every Monday at 9 AM. The double-dot creates ranges: "Mon..Fri" means Monday through Friday. Shorthand expressions make common schedules easy: "daily", "weekly", "monthly", "hourly" are all valid. You can also use "minutely" or specific patterns like "*:0/15" for every 15 minutes. The systemd-analyze calendar command is invaluable - it parses your expression, shows the normalized form, and tells you exactly when the next execution will be. Always test complex expressions with this command before deploying.

Monotonic Timers

Monotonic timers trigger relative to a reference point (boot time, unit activation, etc.) rather than wall-clock time.

Directive	Triggers Relative To	Example
OnBootSec=	System boot	OnBootSec=5min
OnStartupSec=	systemd start (similar to boot)	OnStartupSec=10min
OnActiveSec=	Timer activation	OnActiveSec=1h
OnUnitActiveSec=	Last activation of triggered unit	OnUnitActiveSec=30min
OnUnitInactiveSec=	Last deactivation of triggered unit	OnUnitInactiveSec=1h

# Timer that runs 5 minutes after boot, then every hour
[Timer]
OnBootSec=5min
OnUnitActiveSec=1h

# Timer that runs 15 minutes after boot only
[Timer]
OnBootSec=15min

Monotonic timers trigger relative to events rather than clock time. They're useful when exact time doesn't matter, but interval or boot-relative timing does. OnBootSec triggers a specified time after boot - great for initialization tasks that shouldn't run immediately but soon after startup. OnStartupSec is similar but relative to when systemd itself started. OnActiveSec triggers relative to when the timer was activated - useful for timers that are started manually. OnUnitActiveSec triggers relative to when the service last ran. Combined with itself, it creates a repeating interval: if you set OnUnitActiveSec=1h, the service runs, then one hour later runs again, repeatedly. OnUnitInactiveSec triggers after the service stops. You can combine monotonic and calendar triggers in the same timer. For example, OnBootSec=5min plus OnCalendar=hourly runs 5 minutes after boot AND at every hour mark.

Timer Options

[Timer]
# When to run
OnCalendar=*-*-* 02:00:00

# Run if missed while system was off
Persistent=true

# Add randomized delay (avoid thundering herd)
RandomizedDelaySec=1h

# Accuracy (wake from sleep if needed)
AccuracySec=1min

# Activate different unit than default
Unit=my-special.service

Persistent=true: If the system was off when the timer should have fired, run the job when the system starts. Critical for maintenance tasks!

RandomizedDelaySec: Prevents all systems from running the same job simultaneously. Important for distributed environments.

Timer options fine-tune behavior. Persistent=true is crucial for system maintenance tasks. If a daily job should have run at 2 AM but the system was off, Persistent ensures it runs when the system starts. Without this, the job is simply skipped. RandomizedDelaySec adds a random delay up to the specified value. If you have 100 servers all scheduled to update at 2 AM, they'd all hit the update servers simultaneously. Adding RandomizedDelaySec=1h spreads them over an hour window. AccuracySec controls how precisely the timer fires. The default is 1 minute. Lower values use more resources but are more accurate. For most system tasks, the default is fine. Unit= specifies which service to activate. By default, a timer activates a service with the same name. If backup.timer should activate nightly-backup.service instead of backup.service, use Unit=nightly-backup.service.

Creating a Custom Timer

# Create the service unit
[root@server ~]# vim /etc/systemd/system/cleanup.service

[Unit]
Description=Weekly Cleanup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/weekly-cleanup.sh
StandardOutput=journal
StandardError=journal

# Create the timer unit
[root@server ~]# vim /etc/systemd/system/cleanup.timer

[Unit]
Description=Weekly Cleanup Timer

[Timer]
OnCalendar=Sun *-*-* 03:00:00
Persistent=true
RandomizedDelaySec=30min

[Install]
WantedBy=timers.target

# Enable and start
[root@server ~]# systemctl daemon-reload
[root@server ~]# systemctl enable --now cleanup.timer
[root@server ~]# systemctl list-timers cleanup.timer

Let's walk through creating a complete custom timer. First, create the service unit that defines what to run. Type=oneshot is standard for scheduled tasks - the service runs, completes, and exits. StandardOutput and StandardError set to journal ensures output goes to the system journal for later review. Next, create the timer unit. OnCalendar sets the schedule - here, every Sunday at 3 AM. Persistent=true ensures missed runs are caught up. RandomizedDelaySec spreads execution across a 30-minute window. The [Install] section with WantedBy=timers.target ensures the timer starts at boot when enabled. After creating both files, reload the daemon configuration, then enable and start the timer. The --now flag with enable both enables the unit for future boots AND starts it immediately. Verify with list-timers to see when it will next run.

Managing Timers

# List all timers (active and inactive)
[root@server ~]# systemctl list-timers --all

# Check timer status
[root@server ~]# systemctl status cleanup.timer

# Enable timer to start at boot
[root@server ~]# systemctl enable cleanup.timer

# Start timer now
[root@server ~]# systemctl start cleanup.timer

# Stop timer
[root@server ~]# systemctl stop cleanup.timer

# Disable timer (won't start at boot)
[root@server ~]# systemctl disable cleanup.timer

# Manually trigger the associated service
[root@server ~]# systemctl start cleanup.service

# View logs from timer-triggered service
[root@server ~]# journalctl -u cleanup.service

# View recent timer activity
[root@server ~]# journalctl -u cleanup.timer --since "1 week ago"

Managing timers uses the same systemctl commands as other units. list-timers shows scheduled timers with next/last run times. Adding --all includes inactive timers. status shows the timer's state, when it's scheduled, and recent log entries. enable/disable controls whether the timer starts at boot. start/stop controls the timer's current state. A stopped timer won't fire until started again. An important distinction: starting the timer doesn't run the service - it just starts the timer waiting for the scheduled time. To run the service immediately for testing, start the service directly: systemctl start cleanup.service. Use journalctl to view logs. -u cleanup.service shows output from the service runs. -u cleanup.timer shows timer activation events. Add time filters like --since to limit output. This logging integration is a major advantage over cron, where output handling requires manual configuration.

System Crontab

The system crontab /etc/crontab has an extra field specifying which user runs each job. Only root can edit this file.

[root@server ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue...
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

# MIN HOUR DOM MON DOW USER    COMMAND
  0   3    *   *   *   root    /usr/local/bin/backup.sh
 30   4    *   *   0   root    /usr/local/bin/weekly-maintenance.sh

Note: The username field between day-of-week and command is what distinguishes /etc/crontab from user crontabs.

The system crontab at /etc/crontab is the traditional location for system-wide scheduled tasks. Its format differs from user crontabs by including a username field. This sixth field (between day-of-week and command) specifies which user account runs the job. Usually it's root for system tasks, but could be a service account. Environment variables at the top apply to all jobs. SHELL specifies the shell for running commands. PATH is typically limited - always use absolute paths in commands. MAILTO determines where cron sends output - set to root or an admin email. The system crontab is managed differently from user crontabs. Edit it directly with a text editor (as root), not with crontab -e. Changes take effect immediately - no reload needed. On modern RHEL systems, /etc/crontab is often nearly empty, with jobs placed in /etc/cron.d/ instead.

The /etc/cron.d/ Directory

Drop-in crontab files in /etc/cron.d/ use the same format as /etc/crontab (with username field). Packages install their cron jobs here.

# List cron.d contents
[root@server ~]# ls -la /etc/cron.d/
-rw-r--r--. 1 root root  128 Jan 10 10:00 0hourly
-rw-r--r--. 1 root root  108 Jan 10 10:00 raid-check
-rw-r--r--. 1 root root  121 Jan 10 10:00 sysstat

# View a cron.d file
[root@server ~]# cat /etc/cron.d/sysstat
# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1 -S DISK
# Generate daily summary at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

# Create a custom cron.d file
[root@server ~]# vim /etc/cron.d/myapp
# MyApp maintenance
0 2 * * * root /opt/myapp/bin/maintenance.sh

Advantages: Each application can have its own file. Removing the package removes its cron file. Easier to manage than one big crontab.

The /etc/cron.d/ directory holds individual crontab-format files. Each file uses the same syntax as /etc/crontab, including the username field. This approach has several advantages over a single /etc/crontab. Each application or function can have its own file, making organization cleaner. When a package is removed, its cron file can be removed too. Different administrators can manage different files without merge conflicts. Files must be owned by root and not writable by others, or cron ignores them for security. The filename can be anything - it doesn't need a .cron extension. Lines starting with # are comments. Some common files you'll find: 0hourly runs jobs in /etc/cron.hourly, sysstat collects system statistics, and packages may add their own. Create your own files here for system-level scheduled tasks rather than editing /etc/crontab.

Cron Directories

/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
[root@server ~]# ls -la /etc/cron.daily/
-rwxr-xr-x. 1 root root  219 Jan 10 logrotate
-rwxr-xr-x. 1 root root  618 Jan 10 man-db
-rwxr-xr-x. 1 root root  608 Jan 10 mlocate

# Add a custom daily script
[root@server ~]# vim /etc/cron.daily/custom-cleanup
[root@server ~]# chmod +x /etc/cron.daily/custom-cleanup

# Scripts must be executable!
[root@server ~]# ls -l /etc/cron.daily/custom-cleanup
-rwxr-xr-x. 1 root root 156 Jan 20 15:00 custom-cleanup

Important: Scripts must be executable (chmod +x) and should not have file extensions like .sh (run-parts skips files with dots).

The cron directories provide the simplest scheduling method - just drop an executable script in the appropriate directory. No crontab syntax needed. Scripts in cron.hourly run every hour, cron.daily runs daily, and so on. These are processed by run-parts, which executes all scripts in a directory in alphabetical order. Important requirements: scripts MUST be executable (chmod +x). Scripts should NOT have extensions like .sh - run-parts ignores files with dots in the name by default. This catches many people. Scripts run as root. On RHEL, cron.daily, weekly, and monthly are typically run by anacron, not crond directly. This means they'll run even if the system was off at the scheduled time. cron.hourly is run by crond through /etc/cron.d/0hourly. Common scripts in cron.daily include logrotate for log rotation, man-db for updating man page indexes, and mlocate for updating the locate database.

anacron

anacron runs jobs that were scheduled but missed because the system was off. It ensures daily, weekly, and monthly jobs eventually run.

[root@server ~]# cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
RANDOM_DELAY=45
START_HOURS_RANGE=3-22

#period  delay  job-identifier    command
1        5      cron.daily        nice run-parts /etc/cron.daily
7        25     cron.weekly       nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly      nice run-parts /etc/cron.monthly

# Check when jobs last ran
[root@server ~]# ls -la /var/spool/anacron/
-rw-------. 1 root root 9 Jan 20 03:15 cron.daily
-rw-------. 1 root root 9 Jan 14 03:30 cron.weekly
-rw-------. 1 root root 9 Jan  1 03:45 cron.monthly

Anacron solves a fundamental problem: what happens to daily jobs if the system is off at the scheduled time? With regular cron, they're simply skipped. Anacron tracks when jobs last ran and ensures they run if they're overdue. The anacrontab format differs from crontab. The period field is days between runs (1=daily, 7=weekly, @monthly). The delay field is minutes to wait after anacron starts. Job identifier names the job for tracking. Command is what to run. RANDOM_DELAY adds randomization to prevent simultaneous execution across many systems. START_HOURS_RANGE limits when jobs can start - by default, not during nighttime hours when users might be sleeping. Anacron records the last run date in /var/spool/anacron/. When anacron starts, it checks these timestamps. If a job is overdue, it waits the delay period, then runs the job. On RHEL, anacron is typically triggered by a systemd timer or crond, running daily, weekly, and monthly jobs through the cron directories.

systemd-tmpfiles

systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files and directories based on configuration files.

# Run tmpfiles cleanup manually
[root@server ~]# systemd-tmpfiles --clean

# Create configured files/directories
[root@server ~]# systemd-tmpfiles --create

# View the cleanup timer
[root@server ~]# systemctl status systemd-tmpfiles-clean.timer
● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Active: active (waiting)
    Trigger: Sun 2024-01-21 00:00:00 EST; 5h left

# Configuration file locations
/etc/tmpfiles.d/*.conf          # Local admin configuration
/run/tmpfiles.d/*.conf          # Runtime configuration
/usr/lib/tmpfiles.d/*.conf      # Package defaults

systemd-tmpfiles manages temporary files and directories. It runs at boot (--create) to set up required directories, and periodically (--clean) to remove old files. The systemd-tmpfiles-clean.timer triggers daily cleanup by default, removing files older than their configured age from temporary directories. Configuration files use a specific format specifying what to create, clean, or remove. Files in /etc/tmpfiles.d/ override those in /usr/lib/tmpfiles.d/. This handles things like: creating /run subdirectories needed by services at boot, cleaning /tmp of files older than 10 days, ensuring proper permissions on system directories, and removing stale lock files. You can run tmpfiles manually: --create sets up directories and files, --clean removes old files. These operations are automatically triggered at appropriate times, but manual runs help for testing.

tmpfiles.d Configuration

# Format: Type Path Mode User Group Age Argument

# Create directory with permissions
d /run/myapp 0755 myapp myapp -

# Create directory, clean files older than 10 days
D /var/tmp/myapp 0755 root root 10d

# Create empty file
f /var/log/myapp.log 0644 myapp myapp -

# Create symlink
L /var/run/myapp - - - - /run/myapp

# Remove path recursively
R /tmp/oldcache - - - - -

# Clean files older than 30 days (Age field)
e /var/cache/myapp - - - 30d

# Create custom tmpfiles configuration
[root@server ~]# vim /etc/tmpfiles.d/myapp.conf
# MyApp tmpfiles configuration
d /run/myapp 0755 myapp myapp -
f /run/myapp/app.pid 0644 myapp myapp -
D /var/tmp/myapp 0750 myapp myapp 7d

# Test the configuration
[root@server ~]# systemd-tmpfiles --create /etc/tmpfiles.d/myapp.conf

The tmpfiles.d format has specific fields. Type specifies the action: 'd' creates a directory, 'D' creates and cleans a directory, 'f' creates a file, 'L' creates a symlink, 'R' removes recursively, 'e' cleans a directory without creating it. Path is the filesystem path to act on. Mode sets permissions (or - to skip). User and Group set ownership (or - for default). Age specifies when files are considered old enough to clean (10d = 10 days, 1w = 1 week). Only relevant for types that clean. Argument is type-specific - for symlinks, it's the target. Put custom configurations in /etc/tmpfiles.d/ with a .conf extension. Test new configurations with systemd-tmpfiles --create /path/to/file.conf. Common uses: creating /run directories that don't survive reboot, cleaning application caches, maintaining log directories, and ensuring proper permissions on system directories.

Comparing Methods

Feature	systemd Timers	cron/anacron
Dependency handling	Full systemd dependencies	None
Logging	journald integration	Mail or manual redirect
Missed job handling	Persistent=true	anacron
Random delay	RandomizedDelaySec	RANDOM_DELAY in anacrontab
Resource control	Full cgroup support	Limited (nice)
Calendar syntax	OnCalendar (readable)	5-field format
Boot-relative	OnBootSec, OnStartupSec	@reboot only
Testing	systemd-analyze calendar	Limited
Status visibility	systemctl status	No built-in
Familiarity	Newer, learning curve	Traditional, well-known

Recommendation: Use systemd timers for new system services. Use cron for simpler tasks or when compatibility with non-systemd systems matters.

Let's compare systemd timers and cron to understand when to use each. Systemd timers offer richer features: full dependency management (wait for network, databases, etc.), integrated journald logging, resource controls through cgroups (limit CPU, memory), and better visibility through systemctl status. Cron is simpler and more universally understood. Every Unix admin knows cron. It's available on non-Linux systems and doesn't require systemd knowledge. Anacron fills cron's gap for systems that aren't always on. For new system services on RHEL, systemd timers are generally preferred. They integrate better with the rest of systemd and offer more control. For simple scripts, quick tasks, or cross-platform compatibility, cron remains excellent. Many existing systems use cron, and there's nothing wrong with continuing to use it. The two can coexist - use whichever fits each specific task better.

Common System Timers

[root@server ~]# systemctl list-timers
NEXT                        LEFT       LAST                        PASSED    UNIT                         ACTIVATES
Sun 2024-01-21 00:00:00 EST 4h left    Sat 2024-01-20 00:00:00 EST 19h ago   logrotate.timer              logrotate.service
Sun 2024-01-21 00:00:00 EST 4h left    Sat 2024-01-20 00:00:00 EST 19h ago   systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2024-01-22 00:00:00 EST 1 day left Mon 2024-01-15 00:00:00 EST 5 days    fstrim.timer                 fstrim.service
Sun 2024-01-21 06:00:00 EST 10h left   Sat 2024-01-20 06:12:00 EST 13h ago   dnf-makecache.timer          dnf-makecache.service

Timer	Purpose	Default Schedule
logrotate.timer	Rotate log files to prevent disk fill	Daily
systemd-tmpfiles-clean.timer	Clean temporary directories	Daily
fstrim.timer	Discard unused SSD blocks	Weekly
dnf-makecache.timer	Refresh package metadata	Hourly (with conditions)
unbound-anchor.timer	Update DNSSEC root anchor	Monthly

RHEL includes several important system timers by default. Understanding them helps you manage system health. logrotate.timer runs daily to rotate log files, preventing /var/log from filling up. It compresses old logs and removes ancient ones based on /etc/logrotate.conf. systemd-tmpfiles-clean.timer runs daily to clean temporary directories. It removes old files from /tmp, /var/tmp, and other locations based on tmpfiles.d configuration. fstrim.timer runs weekly to send TRIM commands to SSDs, informing them which blocks are unused. This maintains SSD performance and longevity. dnf-makecache.timer refreshes the DNF package cache, keeping package metadata up to date for faster installs. It runs hourly but has conditions that prevent runs if the system just booted or hasn't been up long. You can check status of any timer with systemctl status, and view when they last ran and next will run with list-timers.

Troubleshooting

# Check if timers/cron daemon running
[root@server ~]# systemctl status crond
[root@server ~]# systemctl list-timers --all

# View systemd timer logs
[root@server ~]# journalctl -u backup.timer
[root@server ~]# journalctl -u backup.service --since "1 day ago"

# View cron logs
[root@server ~]# grep CRON /var/log/cron
[root@server ~]# journalctl -u crond --since "1 hour ago"

# Test timer calendar expression
[root@server ~]# systemd-analyze calendar "Mon *-*-* 09:00:00"

# Manually run a timer's service
[root@server ~]# systemctl start backup.service

# Verify cron.d file permissions
[root@server ~]# ls -la /etc/cron.d/
# Files must be owned by root, not group/world writable

# Check cron directory scripts are executable
[root@server ~]# ls -la /etc/cron.daily/

When scheduled jobs don't run, follow this troubleshooting process. First, verify the scheduling daemon is running - crond for cron, and check that your timer is active for systemd. View logs to see what happened. For systemd, journalctl shows timer and service activity. For cron, check /var/log/cron or journalctl -u crond. Test timer expressions with systemd-analyze calendar before deploying. It shows exactly when the next run will be. Manually trigger the service or script to verify it works outside the scheduling context. This isolates whether the problem is the schedule or the task itself. For cron, check permissions. Files in /etc/cron.d/ must be owned by root and not world-writable. Scripts in cron.daily etc. must be executable. Common issues: service not enabled/started, wrong calendar expression, script not executable, permission problems, missing dependencies in the environment, and output going nowhere (add logging!).

Best Practices

✓ Do

Use systemd timers for new services
Set Persistent=true for maintenance jobs
Use RandomizedDelaySec in clusters
Log all job output to journald or files
Test scripts manually before scheduling
Use /etc/cron.d/ over /etc/crontab
Monitor job success/failure
Document what each job does

✗ Don't

Schedule intensive jobs during peak hours
Forget dependencies (network, mounts)
Use .sh extension in cron directories
Ignore failed job notifications
Hardcode paths without testing
Schedule conflicting jobs at same time
Forget to enable timers after creating
Assume the environment is your shell

Security: System scheduled jobs run as root by default. Use dedicated service accounts when possible. Validate all inputs.

Following best practices ensures reliable system scheduling. Use systemd timers for new services to get modern features. Set Persistent=true so maintenance jobs run after outages. Use RandomizedDelaySec when you have multiple systems hitting shared resources. Always capture output - send it to journald (default for systemd) or redirect to log files for cron. Silent failures are the worst kind. Test everything manually first. A script that fails in its scheduled context wastes time debugging. Prefer /etc/cron.d/ files over editing /etc/crontab - it's cleaner and package-friendly. Avoid scheduling intensive jobs during business hours when users need resources. Remember that scripts in cron.daily etc. must NOT have extensions - run-parts skips them. Don't forget that the execution environment differs from your interactive shell - test in similar conditions. Security matters: scheduled jobs often run as root. Use service accounts when possible, validate inputs, and be careful with scripts that process external data.

Key Takeaways

systemd Timers: Modern scheduling with .timer + .service units. OnCalendar syntax, Persistent=true, journald logging

System Cron: /etc/crontab and /etc/cron.d/ with username field. Cron directories for simple daily/weekly/monthly jobs

anacron: Catches missed jobs on non-24/7 systems. Runs overdue daily/weekly/monthly jobs at startup

systemd-tmpfiles: Creates and cleans temporary files. Configure in /etc/tmpfiles.d/*.conf

Next: Managing Temporary Files

Let's summarize the key system scheduling skills. Systemd timers are the modern approach - create a .timer unit specifying the schedule (OnCalendar for calendar time, or OnBootSec for relative time), paired with a .service unit defining the task. Use Persistent=true to catch up after downtime. System cron provides traditional scheduling through /etc/crontab and /etc/cron.d/, which include a username field specifying who runs each job. The cron directories (daily, weekly, monthly) offer simple drop-in script scheduling. Anacron ensures daily, weekly, and monthly jobs run even on systems that aren't continuously powered - essential for laptops and desktops. It checks timestamps and runs overdue jobs at startup. Systemd-tmpfiles handles temporary file management - creating directories at boot, cleaning old files periodically. Configure it in /etc/tmpfiles.d/.