List of Systemctl Timers Failed in Last Run

Use the command systemctl list-timers --failed to display all systemd timers that encountered errors during their most recent scheduled execution. This diagnostic tool provides immediate visibility into failed automation tasks, allowing administrators to quickly identify broken schedules without sifting through verbose system logs manually.

The Primary Diagnostic Command

The core solution for identifying problematic timers is straightforward. Open your terminal and execute the following command with appropriate privileges:

sudo systemctl list-timers --failed

This command filters the standard timer output to show only those units where the last run resulted in a non-zero exit status or was interrupted by a signal. The output includes critical details such as the next scheduled activation time, the unit name, and the specific service it triggers. If no timers have failed recently, the command returns an empty list, indicating that your scheduled tasks are running cleanly. It is important to note that this command checks the status of the timer unit itself, not necessarily the service unit. However, since timers trigger services, a failure in the timer usually implies an issue with the underlying service configuration or permissions. For context on managing permissions that might affect these runs, you can review our guide on Run Programs with Elevated Privileges: A Comprehensive Guide.

Interpreting the Output Columns

Understanding the columns in the output is essential for effective troubleshooting. The primary fields include:

• LEFT: The time remaining until the next scheduled run. If this shows "n/a", the timer may be disabled or masked.
• NEXT: The absolute timestamp when the timer will fire again.
• LAST: The timestamp of the last successful or failed execution. This is crucial for correlating failures with system events.
• UNIT: The name of the timer unit file (e.g., my-backup.timer).
• ACTIVATES: The name of the service unit that gets activated when the timer fires (e.g., my-backup.service).

If the LAST column shows a time but the timer is marked as failed, check the journal for that specific service. The failure might not be in the timer logic itself, but in the script or application invoked by the service.

Deep Dive into Service Failures

While list-timers --failed identifies the symptom, you must investigate the root cause within the associated service. Use the following command to view detailed logs for a specific failing service:

journalctl -u my-failing-service.service --no-pager -n 50

Replace my-failing-service.service with the actual name found in the ACTIVATES column. Look for error messages related to missing files, permission denied errors, or syntax issues in scripts. Common causes include incorrect paths in the ExecStart directive or environment variables not being loaded correctly. If your service requires specific user contexts or group memberships, ensure they are defined correctly in the service file. Misconfigured permissions often lead to silent failures that only appear as timer errors. For more insights on handling permission-related issues in Linux environments, consider reading about Fixing "Permission denied" with OpenSSH, as similar principles apply to local service execution.

Manual Trigger and Verification

To verify if a service works independently of the timer, you can manually trigger it using:

sudo systemctl start my-failing-service.service

Check the exit code immediately after:

echo $?

A zero exit code indicates success. If it returns non-zero, the service itself is broken. You can also test the timer's activation capability by resetting its state:

sudo systemctl reset-failed my-failing-timer.timer

This clears the failure flag, allowing you to monitor if the issue persists upon the next scheduled run. If the problem recurs, the root cause remains unaddressed in the service configuration or system dependencies.

Common Configuration Pitfalls

Several common mistakes lead to timer failures. Ensure your .timer file uses correct syntax for OnCalendar or OnUnitActiveSec. Verify that the target service is enabled and not masked. Additionally, check for conflicting cron jobs that might interfere with systemd timers. Systemd and cron do not always play nicely together if they manage the same resources simultaneously. Another frequent issue involves path resolution. Always use absolute paths in ExecStart directives within service files. Relative paths can fail depending on the working directory set by systemd, which defaults to / unless specified otherwise.

Frequently Asked Questions

Why does systemctl list-timers --failed show nothing even though my script isn't running?

If the timer hasn't fired yet or has never failed, the list will remain empty. Check the LEFT column to see when the next run is scheduled. If the timer is disabled, it won't fire at all, so you must enable it first using systemctl enable.

Can I clear the failed status without fixing the underlying issue?

Yes, you can use systemctl reset-failed to clear the failure flag, but this is only a temporary cosmetic fix. The timer will likely fail again on the next scheduled run if the root cause in the service configuration remains unresolved.

How do I debug a timer that fails silently?

Silent failures often occur because the service exits with code zero despite doing nothing useful. Enable verbose logging in your service file by adding StandardOutput=journal and StandardError=journal. Then check the journal for any unexpected behavior or empty outputs.

What is the difference between a failed timer and a failed service?

A failed timer means the scheduling mechanism itself encountered an error, such as invalid calendar syntax. A failed service means the task triggered by the timer crashed or returned an error code. Most issues are actually service failures misinterpreted as timer failures because the timer reports the outcome of the activation.

Does Dropbox auto-update issues relate to systemd timer failures?

While unrelated directly, some users confuse update mechanisms. If you are experiencing issues with applications like Dropbox not updating, it might be due to systemd service configurations rather than timers. You can explore Dropbox Not Automatically Updating on Ubuntu for specific application-level troubleshooting steps.