Scheduled Tasks (Timers)

systemd timers are a modern alternative to cron, offering more precise scheduling control, seamless log integration, and dependency management capabilities. On CentOS/AlmaLinux/Rocky Linux, an increasing number of system tasks have been migrated from cron to systemd timers.

Timers vs. Cron

Feature	systemd Timer	Cron
Log integration	Automatically integrates with journald; viewable via journalctl	Requires manual log redirection
Dependency management	Supports After=, Requires=, and other dependency declarations	No dependency management
Missed executions	Supports Persistent=true; missed tasks run at next startup	Missed tasks are lost
Resource control	Can set CPU, memory, and IO limits	No resource control
Precision	Supports microsecond-level precision	Minimum granularity is 1 minute
Boot delay	Supports OnBootSec= and other relative time triggers	Not supported
Random delay	Supports RandomizedDelaySec= to spread load	Not supported
Management	Unified management via systemctl	Requires editing crontab files

How Timers Work

systemd timers work in pairs: each .timer unit corresponds to a .service unit with the same name. When the timer triggers, systemd automatically starts the corresponding service unit.

For example:

• backup.timer — Defines the trigger schedule
• backup.service — Defines the task to execute

Two Types of Timers

Monotonic Timers

Triggered based on relative time, suitable for “how long since a certain event” scenarios:

Directive	Description
OnBootSec=	Trigger after a specified time since system boot
OnActiveSec=	Trigger after a specified time since the timer was activated
OnStartupSec=	Trigger after a specified time since systemd started
OnUnitActiveSec=	Trigger after a specified time since the corresponding service was last activated
OnUnitInactiveSec=	Trigger after a specified time since the corresponding service last completed

Calendar Timers (Realtime)

Triggered based on absolute time, similar to cron scheduling:

Directive	Description
OnCalendar=	Trigger according to a calendar time expression

OnCalendar Time Syntax

OnCalendar= uses the following format:

DayOfWeek Year-Month-Day Hour:Minute:Second

Common Time Expressions

Expression	Description	Cron Equivalent
*-*-* 00:00:00	Every day at midnight	0 0 * * *
*-*-* *:00:00	Every hour on the hour	0 * * * *
*-*-* *:*:00	Every minute	* * * * *
*-*-01 00:00:00	1st of every month at midnight	0 0 1 * *
Mon *-*-* 08:00:00	Every Monday at 8:00 AM	0 8 * * 1
Mon..Fri *-*-* 18:00:00	Weekdays at 6:00 PM	0 18 * * 1-5
*-*-* 06,18:00:00	Every day at 6:00 AM and 6:00 PM	0 6,18 * * *
*-*-* 09:00:00/2h	Every 2 hours starting at 9:00 AM	—

systemd also provides convenient presets:

Preset	Equivalent Expression
minutely	*-*-* *:*:00
hourly	*-*-* *:00:00
daily	*-*-* 00:00:00
weekly	Mon *-*-* 00:00:00
monthly	*-*-01 00:00:00
yearly	*-01-01 00:00:00

Verifying Time Expressions

Use systemd-analyze calendar to verify whether an expression is correct and preview upcoming trigger times:

Verify a time expression and view the next trigger time

systemd-analyze calendar "Mon..Fri *-*-* 09:00:00"

Verify an expression that triggers every 15 minutes

systemd-analyze calendar "*-*-* *:00/15:00"

Creating a Scheduled Task: Complete Example

The following example demonstrates how to create a timer + service pair using a database backup task.

Step 1: Create the Backup Script

Create the backup script

sudo vim /opt/scripts/db-backup.sh

Enter the following content:

/opt/scripts/db-backup.sh

#!/bin/bash
BACKUP_DIR="/backup/database"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"
mysqldump --all-databases | gzip > "$BACKUP_DIR/all-db-$TIMESTAMP.sql.gz"
# Delete backups older than 7 days
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +7 -delete
echo "Database backup completed: all-db-$TIMESTAMP.sql.gz"

Grant execute permission to the script

sudo chmod +x /opt/scripts/db-backup.sh

Step 2: Create the Service Unit File

Create the backup service unit file

sudo vim /etc/systemd/system/db-backup.service

/etc/systemd/system/db-backup.service

[Unit]
Description=Database Backup Service
After=mariadb.service
Wants=mariadb.service

[Service]
Type=oneshot
ExecStart=/opt/scripts/db-backup.sh
User=root
StandardOutput=journal
StandardError=journal

# Timeout setting (large database backups may take a long time)
TimeoutStartSec=3600

# Security hardening
PrivateTmp=true
ProtectHome=true

Note: Services triggered by timers typically do not need an [Install] section, since they are started by the timer rather than directly enabled.

Step 3: Create the Timer Unit File

Create the backup timer unit file

sudo vim /etc/systemd/system/db-backup.timer

/etc/systemd/system/db-backup.timer

[Unit]
Description=Run Database Backup Daily at 2:00 AM

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

[Install]
WantedBy=timers.target

Configuration details:

Directive	Description
OnCalendar=*-*-* 02:00:00	Trigger every day at 2:00 AM
RandomizedDelaySec=300	Random delay of 0-300 seconds, to avoid multiple servers executing simultaneously
Persistent=true	If the execution time was missed (e.g., server was off), run immediately at next startup

Step 4: Enable the Timer

Reload the systemd configuration

sudo systemctl daemon-reload

Enable and start the timer

sudo systemctl enable --now db-backup.timer

Step 5: Verify the Timer

View the timer status and next trigger time

sudo systemctl status db-backup.timer

Manually trigger the backup service for testing

sudo systemctl start db-backup.service

View the backup service execution logs

sudo journalctl -u db-backup.service -n 20

Using Monotonic Timers

In addition to calendar-based timers, monotonic timers are suitable for “execute at regular intervals” scenarios:

/etc/systemd/system/health-check.timer - First run 1 minute after boot, then every 5 minutes

[Unit]
Description=Run Health Check Every 5 Minutes

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

/etc/systemd/system/health-check.service

[Unit]
Description=System Health Check

[Service]
Type=oneshot
ExecStart=/opt/scripts/health-check.sh

Listing and Managing Timers

View All Active Timers

List all active timers and their next trigger times

systemctl list-timers

View All Timers (Including Inactive)

List all timers (including disabled ones)

systemctl list-timers --all

Temporarily Stop a Timer

Stop a timer (does not remove the enable)

sudo systemctl stop db-backup.timer

Permanently Disable a Timer

Disable and stop a timer

sudo systemctl disable --now db-backup.timer

Migrating from Cron to Timers

If you have an existing crontab task:

30 3 * * * /opt/scripts/cleanup.sh

The corresponding systemd timer configuration is:

/etc/systemd/system/cleanup.service

[Unit]
Description=Daily Cleanup Task

[Service]
Type=oneshot
ExecStart=/opt/scripts/cleanup.sh

/etc/systemd/system/cleanup.timer

[Unit]
Description=Run Cleanup Daily at 3:30 AM

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

[Install]
WantedBy=timers.target

Enable the migrated timer

sudo systemctl daemon-reload && sudo systemctl enable --now cleanup.timer

After confirming the timer is working correctly, remove the corresponding crontab entry:

Edit crontab to remove the old task

sudo crontab -e

Troubleshooting Timer Issues

View detailed timer status

sudo systemctl status db-backup.timer

View the most recent execution result of the timer's associated service

sudo systemctl status db-backup.service

View all properties of the timer

systemctl show db-backup.timer

Verify OnCalendar expression syntax

systemd-analyze calendar "*-*-* 02:00:00"

View the complete logs for both the timer and service

sudo journalctl -u db-backup.timer -u db-backup.service --since today