Decoupling Execution Logic from Timing Logic

In this lesson, you will learn how to improve system maintainability by separating the "what" (your automation script) from the "when" (the scheduling mechanism).

The Problem with Tight Coupling

When you embed complex logic directly into a cron entry or a hard-coded systemd timer definition, you create a rigid system. If you want to change the frequency of a task, you modify the scheduler; if you want to update the logic, you modify the script. When these are tangled—for example, by putting complex if statements directly inside a crontab line—the script becomes brittle, difficult to test in isolation, and a nightmare to debug.

Separating Concerns

To decouple these, you should treat your operational script as a self-contained, idempotent unit that performs a single task. The execution logic should not know—or care—how often it is called. Meanwhile, the timing logic should simply act as a "trigger" that invokes your script without passing it complex parameters or relying on the script's internal state to decide when to run.

Consider this modular approach:

1. The Execution Unit (/usr/local/bin/backup-db.sh): This script handles the database dump, compression, and cleanup. It is designed to be executable from any shell at any time.
2. The Timing Mechanism (/etc/systemd/system/backup-db.timer): This unit manages the frequency (e.g., OnCalendar=daily).

By isolating the script, you can trigger it manually for testing or force-run it during an incident without triggering the timer’s conditions. You can also swap the timing mechanism (e.g., switching from cron to a systemd timer) without ever touching the source code of the backup script itself.

Best Practices

• Standardize entry points: Ensure your script functions correctly whether it is run by a user, a cron job, or a systemd unit.
• Keep configuration external: Avoid hard-coding schedule-related variables (like "run once a day") inside your script. If your script requires state awareness, use a simple lockfile or a status file to ensure idempotency.
• Avoid "One-Liners" in schedulers: Never use complex shell logic inside a crontab or ExecStart line; always call an external script file.

Key Takeaway: By isolating execution logic from timing logic, you create modular, testable automation that remains stable even when scheduling requirements change.