systemd timers in Linux CLI - Commands & Configuration

Introduction

Systemd timers let you run tasks automatically at set times or intervals on Linux. They solve the problem of needing to run scripts or commands regularly without manual effort.

When you want to run a backup script every day at midnight without logging in.

When you need to check system health every hour automatically.

When you want to clean temporary files weekly without manual commands.

When you want to send a reminder email every Monday morning.

When you want to restart a service every day to keep it fresh.

Config File - mytask.timer

mytask.timer

[Unit]
Description=Run mytask.service every minute

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

[Unit] describes the timer unit and its purpose.

[Timer] sets when the timer triggers: 1 minute after boot and then every 1 minute.

[Install] makes the timer start when timers.target is active, enabling it to run automatically.

Commands

This command starts the timer immediately so it begins counting down to run the task.

Terminal

sudo systemctl start mytask.timer

Expected Output

No output (command runs silently)

This enables the timer to start automatically on system boot.

Terminal

sudo systemctl enable mytask.timer

Expected Output

Created symlink /etc/systemd/system/timers.target.wants/mytask.timer → /etc/systemd/system/mytask.timer.

This shows all timers on the system, including when they last ran and when they will run next.

Terminal

systemctl list-timers --all

Expected Output

NEXT                         LEFT          LAST                         PASSED       UNIT            ACTIVATES

Fri 2024-06-07 12:01:00 UTC  59s left      Fri 2024-06-07 12:00:00 UTC  1min ago    mytask.timer    mytask.service



1 timers listed.

This shows the logs of the service that the timer triggers, so you can check if the task ran successfully.

Terminal

journalctl -u mytask.service

Expected Output

-- Logs begin at Fri 2024-06-07 11:00:00 UTC, end at Fri 2024-06-07 12:00:00 UTC.

Jun 07 12:00:00 hostname systemd[1]: Started My Task Service.

Jun 07 12:00:00 hostname mytask[1234]: Task executed successfully.

Key Concept

If you remember nothing else from systemd timers, remember: they schedule and run services automatically at set times without needing cron.

Common Mistakes

Not enabling the timer after creating it.

The timer won't start automatically on boot and only runs if started manually.

Always run 'sudo systemctl enable mytask.timer' to make it start on boot.

Creating a timer without a matching service file.

The timer triggers a service unit; without it, nothing runs.

Create a .service file with the same base name as the timer to define the task.

Using wrong time settings like OnActiveSec without understanding when it triggers.

The timer may not run when expected if time settings are misunderstood.

Use OnBootSec for delay after boot and OnUnitActiveSec for intervals after last run.

Summary

Create a .timer file to define when a task runs and a matching .service file to define what runs.

Use 'systemctl start' to run the timer now and 'systemctl enable' to run it on boot.

Check timers with 'systemctl list-timers' and logs with 'journalctl -u servicename'.

Practice

1. What is the main purpose of a systemd timer in Linux?

easy

A. To manage user permissions

B. To schedule and run tasks automatically at specified times

C. To monitor system hardware status

D. To update software packages automatically

Solution

1. Step 1: Understand systemd timer role

   Systemd timers are designed to schedule tasks to run automatically without manual intervention.

2. Step 2: Compare with other options

   Monitoring hardware, managing permissions, and updating packages are not the primary roles of systemd timers.

3. Final Answer:

   To schedule and run tasks automatically at specified times -> Option B

4. Quick Check:

   Systemd timers = schedule tasks [OK]

Hint: Timers schedule tasks like alarms for programs [OK]

Common Mistakes:

• Confusing timers with monitoring tools
• Thinking timers manage user permissions
• Assuming timers update software automatically

2. Which of the following is the correct syntax to enable a systemd timer named backup.timer?

easy

A. systemctl enable backup.timer

B. systemctl start backup.timer

C. systemctl run backup.timer

D. systemctl activate backup.timer

Solution

1. Step 1: Identify enabling command for systemd timers

   The command systemctl enable sets a timer to start automatically on boot.

2. Step 2: Differentiate from other commands

   start runs the timer immediately but does not enable it; run and activate are invalid commands.

3. Final Answer:

   systemctl enable backup.timer -> Option A

4. Quick Check:

   Enable timer = systemctl enable [OK]

Hint: Use 'enable' to start timer on boot, 'start' to run now [OK]

Common Mistakes:

• Using 'start' instead of 'enable' to auto-run timers
• Using invalid commands like 'run' or 'activate'
• Confusing service commands with timer commands

3. Given this timer unit file snippet:

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

What does the Persistent=true setting do?

medium

A. Prevents the timer from running at boot

B. Runs the timer only once

C. Disables the timer after one run

D. Runs missed jobs immediately after boot

Solution

1. Step 1: Understand Persistent=true meaning

   This setting makes systemd run any missed timer jobs immediately after the system boots.

2. Step 2: Eliminate other options

   It does not limit runs to once, disable timers, or prevent running at boot.

3. Final Answer:

   Runs missed jobs immediately after boot -> Option D

4. Quick Check:

   Persistent=true = catch missed runs after reboot [OK]

Hint: Persistent=true runs missed tasks after reboot [OK]

Common Mistakes:

• Thinking it runs only once
• Assuming it disables timer after run
• Believing it prevents timer at boot

4. You created a timer file cleanup.timer but it never triggers the service. Which is the most likely mistake?

medium

A. The timer file is not named exactly like the service file

B. The timer file is missing the [Timer] section

C. The service file cleanup.service is not enabled

D. The timer file uses OnBootSec= instead of OnCalendar=

Solution

1. Step 1: Check timer and service file naming

   Systemd timers must have matching names with their service files except for the extension.

2. Step 2: Analyze other options

   Missing [Timer] section causes syntax errors; service enabling is not required for timers to trigger; both OnBootSec and OnCalendar are valid.

3. Final Answer:

   The timer file is not named exactly like the service file -> Option A

4. Quick Check:

   Timer and service names must match [OK]

Hint: Timer and service filenames must match except extension [OK]

Common Mistakes:

• Ignoring filename matching between timer and service
• Assuming service must be enabled for timer to run
• Confusing valid timer options as errors

5. You want a systemd timer to run a backup service every day at 3:30 AM but only if the system was off at that time. Which timer configuration achieves this?

hard

A. [Timer]
OnActiveSec=03:30:00
Persistent=true

B. [Timer]
OnCalendar=*-*-* 03:30:00
AccuracySec=1min

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

D. [Timer]
OnBootSec=03:30:00
Persistent=false

Solution

1. Step 1: Identify daily schedule at 3:30 AM

   The OnCalendar=*-*-* 03:30:00 sets the timer to run daily at 3:30 AM.

2. Step 2: Ensure missed runs execute after downtime

   Persistent=true makes systemd run missed jobs after system was off at scheduled time.

3. Step 3: Evaluate other options

   AccuracySec adjusts timing precision but doesn't affect missed runs; OnBootSec and OnActiveSec run relative to boot or activation, not fixed time.

4. Final Answer:

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

5. Quick Check:

   Daily 3:30 AM with catch-up = OnCalendar + Persistent [OK]

Hint: Use OnCalendar with Persistent=true for daily missed runs [OK]

Common Mistakes:

• Using OnBootSec instead of OnCalendar for fixed time
• Forgetting Persistent=true to run missed jobs
• Confusing AccuracySec with scheduling behavior