How to Use systemd-timer in Ubuntu Linux for Sub-Minute Precision Task Scheduling

In the world of Linux system administration, the standard tool for scheduling background tasks has always been cron. However, cron suffers from a major limitation: it can only schedule tasks with a minimum resolution of one minute. If you are managing a high-frequency trading application, a real-time sensor data ingestion pipeline, or a high-traffic microservices architecture, waiting 60 seconds between task executions is often unacceptable.

To achieve sub-minute precision on Ubuntu Linux, administrators must move away from legacy cron daemon configurations and leverage the powerful scheduling capabilities built directly into the systemd init system using systemd timers. Systemd timers not only support millisecond-level precision, but they also provide built-in logging via journalctl, prevent overlapping executions, and allow tasks to be triggered by specific hardware events or system states.

Understanding systemd Timer Units

A systemd timer requires two separate configuration files to function correctly: a service unit file (.service) which defines the actual command or script to execute, and a timer unit file (.timer) which defines the scheduling logic. By decoupling the scheduling from the execution, administrators can manually trigger the service for testing purposes without waiting for the timer to fire.

The timer unit utilises the OnCalendar directive for standard cron-like scheduling, or the OnUnitActiveSec directive for monotonic scheduling, which is how we achieve sub-minute execution intervals.

Creating the Execution Service

Before configuring the timer, you must define the service. Open a terminal and create a new service unit file in the systemd directory.

sudo nano /etc/systemd/system/high-frequency-task.service

Add the following configuration, adjusting the ExecStart path to point to your specific script.

[Unit]
Description=High Frequency Background Task Execution
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/my-frequent-script.sh
User=root
Group=root

The Type=oneshot directive ensures that systemd waits for the script to exit before considering the service stopped. This is crucial for preventing overlapping executions if your script takes longer to run than the timer interval.

Configuring the Sub-Minute Timer

Next, create the corresponding timer unit file. It must have the exact same base name as your service file.

sudo nano /etc/systemd/system/high-frequency-task.timer

To execute the task every 15 seconds, use the following configuration:

[Unit]
Description=Timer for High Frequency Background Task

[Timer]
OnBootSec=10sec
OnUnitActiveSec=15sec
AccuracySec=1ms

[Install]
WantedBy=timers.target

The AccuracySec=1ms directive is essential. By default, systemd adds a randomised delay of up to one minute to all timers to prevent CPU spikes caused by multiple tasks waking up simultaneously. Overriding this default value forces systemd to respect the strict 15-second interval.

Enabling and Monitoring the Timer

After creating the unit files, reload the systemd daemon to register the new configurations, then enable and start the timer.

sudo systemctl daemon-reload
sudo systemctl enable high-frequency-task.timer
sudo systemctl start high-frequency-task.timer

You can verify that the timer is active and check when it is next scheduled to execute using the list-timers command:

systemctl list-timers --all | grep high-frequency-task

To review the output of your script, utilise the journalctl utility, which automatically captures any standard output or standard error streams generated by the service.

sudo journalctl -u high-frequency-task.service -f

By migrating from cron to systemd timers, you gain precise control over background task execution, robust logging, and the peace of mind that overlapping script executions are automatically prevented by the operating system.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.