Systemd Units as Automation Objects

In this lesson, you will learn how to transition from traditional cron-based scheduling to using systemd timers as robust, stateful automation objects.

While cron is a simple task scheduler, systemd units treat automation as a formal relationship between two distinct entities: a Service unit (the what) and a Timer unit (the when).

The Decoupling Logic

In a systemd automation workflow, the Service unit is defined exactly like a background daemon. It contains the logic, environment variables, and execution parameters. The Timer unit then acts as a controller for that service. By decoupling the execution logic from the schedule, you can trigger the same service manually, via a timer, or even via a different system event without modifying the script itself.

Concrete Illustration

To automate a task, you create two files in /etc/systemd/system/.

First, define the Service (backup.service):

[Unit]
Description=Run Daily Backup

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

Second, define the Timer (backup.timer):

[Unit]
Description=Timer for Daily Backup

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Why This Beats Cron

Unlike cron, which simply executes a command and forgets it, systemd treats these units as objects with states:

• Observability: You can query the status of your automation object using systemctl status backup.timer to see when it last ran and when it is scheduled next.
• Dependency Tracking: Because the Service is a unit, you can easily add After= or Requires= directives to ensure your task only runs if specific network mounts or services are online.
• Persistence: If your machine is powered down when the timer should have fired, the Persistent=true directive ensures the task runs immediately upon the next boot.

By moving away from cron to systemd units, you turn transient scripts into managed system objects that benefit from the same logging, dependency management, and monitoring as your core system services.

Key Takeaway: In systemd automation, the Service unit defines the task, while the Timer unit manages the schedule, allowing for superior observability and dependency control compared to traditional cron jobs.