systemd timers in Linux CLI - Deep Dive

Overview - systemd timers

What is it?

Systemd timers are a way to schedule tasks on Linux systems using the systemd init system. They work like alarms that tell the system when to run a specific command or script. Instead of using older tools like cron, systemd timers provide more control and integration with system services. They can trigger tasks based on time intervals or calendar events.

Why it matters

Without systemd timers, scheduling tasks would rely on older, less flexible tools like cron, which lack deep integration with system services. Systemd timers allow administrators to manage scheduled tasks with better precision, logging, and dependency handling. This improves system reliability and makes automation easier and more consistent across different Linux distributions.

Where it fits

Before learning systemd timers, you should understand basic Linux command line usage and have a general idea of systemd services. After mastering timers, you can explore advanced systemd features like service dependencies, socket activation, and automating complex workflows.

Mental Model

Core Idea

Systemd timers are like smart alarms that tell your Linux system exactly when and how to run tasks, tightly integrated with system services.

Think of it like...

Imagine a smart home where you set alarms not just to wake you up but also to turn on lights, start the coffee machine, or water plants at precise times. Systemd timers are these smart alarms for your computer tasks.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│ Timer Unit  │──────▶│ systemd Timer │──────▶│ Service Unit  │
│ (defines    │       │ (waits for    │       │ (runs command │
│  schedule)  │       │  schedule)    │       │  or script)   │
└─────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is systemd and its role

Concept: Introduce systemd as the Linux system and service manager that controls how services start and stop.

Systemd is the software that manages how your Linux system boots up, runs services, and shuts down. It replaces older systems like SysVinit. It uses units to represent services, devices, mounts, and timers. Understanding systemd is key to using systemd timers effectively.

Result

You understand that systemd controls system tasks and that timers are one type of unit it manages.

Knowing systemd's role helps you see timers as part of a bigger system management framework, not just standalone schedulers.

2

Foundation

Basics of systemd timer units

Concept: Learn what a timer unit file is and how it schedules tasks.

A systemd timer unit is a configuration file ending with .timer that tells systemd when to activate a corresponding service unit. It contains settings like OnCalendar (for calendar events) or OnUnitActiveSec (for intervals). The timer triggers the service unit to run the actual task.

Result

You can identify timer unit files and understand their basic structure and purpose.

Recognizing the separation between timer and service units clarifies how scheduling and task execution are decoupled.

3

Intermediate

Creating a simple timer and service

🤔Before reading on: do you think a timer unit alone runs commands, or does it need a service unit? Commit to your answer.

Concept: Learn to write a basic timer and service unit pair to run a command periodically.

[Unit] Description=Run my script every minute [Timer] OnUnitActiveSec=1min [Install] WantedBy=timers.target # Save as myscript.timer And the service: [Unit] Description=My script service [Service] Type=oneshot ExecStart=/usr/local/bin/myscript.sh # Save as myscript.service Enable and start the timer with: systemctl enable --now myscript.timer

Result

The script runs every minute as scheduled by the timer triggering the service.

Understanding that timers trigger services to run commands helps you design modular and reusable scheduled tasks.

4

Intermediate

Using OnCalendar for calendar events

🤔Before reading on: do you think OnCalendar can schedule tasks only by fixed intervals or also by specific dates and times? Commit to your answer.

Concept: Learn to schedule tasks at specific times or dates using OnCalendar syntax.

OnCalendar lets you specify calendar events like daily, weekly, or specific dates. Examples: OnCalendar=daily OnCalendar=Mon *-*-* 12:00:00 OnCalendar=*-*-01 00:00:00 (first day of each month) This flexibility allows precise scheduling beyond simple intervals.

Result

You can schedule tasks to run at exact times or recurring calendar events.

Knowing OnCalendar syntax unlocks powerful scheduling options similar to cron but integrated with systemd.

5

Intermediate

Timer activation and persistence

Concept: Understand how timers start, stop, and persist across reboots.

Timers can be enabled to start at boot with systemctl enable. They run in the background and systemd tracks their state. If the system is off when a timer should run, you can configure it to run missed jobs with Persistent=true. This ensures tasks are not skipped.

Result

You can manage timers to run reliably even if the system restarts or was off at scheduled times.

Knowing timer persistence prevents missed tasks and improves automation reliability.

6

Advanced

Combining multiple timers and dependencies

🤔Before reading on: do you think timers can trigger multiple services or depend on other timers? Commit to your answer.

Concept: Learn how to coordinate multiple timers and services with dependencies.

You can create multiple timer-service pairs and use systemd dependencies like Wants= or After= in unit files to control order. For example, one timer can trigger a service that starts another service. This allows complex workflows and chaining of tasks.

Result

You can build sophisticated scheduled workflows with multiple coordinated tasks.

Understanding dependencies lets you automate complex sequences, not just isolated tasks.

7

Expert

Timer accuracy and system sleep handling

🤔Before reading on: do you think systemd timers always run exactly on time, even if the system sleeps? Commit to your answer.

Concept: Explore how timers behave with system sleep and how accuracy is managed.

Systemd timers rely on system clock and can be affected by system sleep or hibernation. Using Persistent=true makes timers run missed jobs after wake-up. Also, AccuracySec= controls how precise the timer is, balancing power and timing needs. Understanding these helps optimize timers for laptops or servers with variable uptime.

Result

You can configure timers to handle system sleep and control timing precision.

Knowing timer behavior with sleep prevents unexpected missed tasks and helps tune system performance.

Under the Hood

Systemd timers are implemented as special unit files that register with the systemd manager. When a timer is active, systemd sets up kernel timers or uses the system clock to wait until the scheduled time. At that moment, systemd activates the linked service unit. The timer state and last trigger time are stored persistently, allowing recovery after reboots or sleep. Internally, systemd uses event-driven mechanisms to efficiently manage many timers without polling.

Why designed this way?

Systemd timers were designed to unify task scheduling with service management, replacing older tools like cron that operated separately. This integration allows better control over dependencies, logging, and system state awareness. Using unit files makes configuration consistent and declarative. Alternatives like cron lack this integration and flexibility, so systemd timers provide a modern, robust solution.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ systemd Timer │──────▶│ systemd Manager│──────▶│ kernel timer  │
│ Unit File     │       │ (event loop)   │       │ (waits clock) │
└───────────────┘       └───────────────┘       └───────────────┘
         │                      │                      │
         │                      │                      ▼
         │                      │             ┌────────────────┐
         │                      │             │ Service Unit   │
         │                      │             │ (runs command) │
         │                      │             └────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does a systemd timer run commands directly without a service unit? Commit to yes or no.

Common Belief: A systemd timer unit runs commands directly without needing a service unit.

Reality: A timer unit only schedules when to run; it triggers a separate service unit that actually runs the command.

Why it matters: Confusing this leads to broken setups where the timer triggers nothing because no service unit is defined.

Quick: Do systemd timers always run missed jobs after system sleep by default? Commit to yes or no.

Common Belief: Systemd timers automatically run missed tasks after the system wakes from sleep without extra configuration.

Reality: Timers only run missed jobs if Persistent=true is set; otherwise, missed runs are skipped.

Why it matters: Without Persistent=true, important scheduled tasks may be silently skipped, causing automation failures.

Quick: Can systemd timers replace all cron jobs without any limitations? Commit to yes or no.

Common Belief: Systemd timers can replace all cron jobs perfectly with no downsides.

Reality: While powerful, systemd timers have different syntax and behavior; some cron features like environment inheritance or complex scripting may require adjustments.

Why it matters: Assuming a drop-in replacement can cause migration errors and unexpected task failures.

Quick: Are systemd timers guaranteed to run exactly on time regardless of system load? Commit to yes or no.

Common Belief: Systemd timers always run tasks exactly at the scheduled time, no matter system load or conditions.

Reality: Timers aim for accuracy but can be delayed by system load, sleep, or configuration like AccuracySec=.

Why it matters: Expecting perfect timing can lead to misjudging task behavior in production, causing timing-sensitive automation to fail.

Expert Zone

1

Timer units can be combined with OnBootSec= and OnStartupSec= to schedule tasks relative to system boot or startup, useful for initialization sequences.

2

Using Persistent=true with timers ensures no scheduled run is missed, but can cause multiple runs at once after long downtime, which needs careful handling.

3

AccuracySec= controls timer precision and power usage tradeoff; setting it too low can increase CPU wakeups, affecting battery life on laptops.

When NOT to use

Systemd timers are not ideal for very high-frequency tasks (sub-second intervals) or complex job scheduling requiring advanced scripting logic; in such cases, specialized schedulers or cron with scripts may be better.

Production Patterns

In production, systemd timers are used to schedule log rotation, backups, system updates, and maintenance tasks. They are often combined with service dependencies to ensure tasks run only after network or storage is ready, improving reliability.

Connections

cron jobs

alternative scheduling tools

Understanding cron helps grasp what systemd timers improve upon: better integration, logging, and dependency management.

event-driven programming

shared event scheduling pattern

Systemd timers use event-driven mechanisms internally, similar to how event loops in programming wait for triggers, making them efficient and scalable.

smart home automation

conceptual scheduling analogy

Just like smart home devices schedule actions based on time or events, systemd timers automate system tasks, showing how automation principles apply across domains.

Common Pitfalls

#1 Defining a timer unit without a matching service unit.

Wrong approach:

[Unit]
Description=My timer

[Timer]
OnCalendar=*-*-* *:00:00

[Install]
WantedBy=timers.target

# No service unit created

Correct approach:

[Unit]
Description=My timer

[Timer]
OnCalendar=*-*-* *:00:00

[Install]
WantedBy=timers.target

# And create mytimer.service:
[Unit]
Description=My service

[Service]
Type=oneshot
ExecStart=/path/to/script.sh

Root cause:

Misunderstanding that timers only schedule triggers and do not run commands themselves.

#2 Not enabling the timer after creating it, so it never starts automatically.

Wrong approach:

systemctl start mytimer.timer
# but no 'enable' command

Correct approach:

systemctl enable --now mytimer.timer

Root cause:

Confusing starting a timer once with enabling it to start on boot.

#3 Assuming timers run missed jobs after system sleep without Persistent=true.

Wrong approach:

[Timer]
OnCalendar=daily
# Persistent not set

Correct approach:

[Timer]
OnCalendar=daily
Persistent=true

Root cause:

Not knowing that Persistent=true is required to catch up missed runs.

Key Takeaways

Systemd timers schedule tasks by triggering service units, separating scheduling from execution.

They provide flexible scheduling options including intervals and calendar events, integrated with systemd's management.

Timers can be made persistent to run missed tasks after downtime, improving reliability.

Understanding timer and service unit relationships is key to effective automation.

Systemd timers offer a modern, unified alternative to cron with better control and logging.