Cron to systemd Timer Converter

A systemd timer is a unit file (.timer) that schedules another systemd unit, almost always a matching .service file. The timer says when to run; the service says what to run. Timers replace cron on systemd-based Linux distributions (Ubuntu, Debian, Fedora, Arch, RHEL, etc.) and integrate with the rest of systemd: logs go to the journal, you can set dependencies on other units with After= and Requires=, and you can apply resource limits via cgroups. There are two main triggers: OnCalendar= for wall-clock schedules (the cron equivalent) and monotonic timers like OnBootSec= and OnUnitActiveSec= that count from a reference event.

Use systemd timers for anything new on a systemd-based system. They log to journalctl alongside everything else, support Persistent=true so missed runs (e.g. while the laptop was asleep) are caught up on next boot, allow RandomizedDelaySec to spread load across a fleet, run inside cgroups for resource isolation, and can declare dependencies on other units. Cron is still fine for quick one-liners on minimal containers without systemd, or when portability across non-Linux Unix systems matters. For everything else, timers are the modern default and most distributions ship core maintenance tasks (logrotate, fstrim, apt updates) as timers rather than cron jobs.

It depends on scope. System-wide timers maintained by you live in /etc/systemd/system/, which is what this tool's install commands use. Distribution-packaged timers live in /usr/lib/systemd/system/ (or /lib/systemd/system/ on Debian) and should not be edited directly — override them with a drop-in at /etc/systemd/system/<unit>.d/override.conf instead. User timers (no root needed) live in ~/.config/systemd/user/ and are managed with systemctl --user. After adding or changing any unit file you must run systemctl daemon-reload before enabling it.

Persistent=true tells systemd to remember the last time the timer fired and to run the service immediately on next boot if a scheduled run was missed while the system was off. Without it, an OnCalendar=daily timer on a laptop that was asleep at 03:00 would simply skip that day. Persistent=true is the closest equivalent to anacron's catch-up behavior, which standard cron does not provide. The state is stored as a timestamp file under /var/lib/systemd/timers/ (or the user equivalent), so the timer must run at least once before the persistence kicks in.

The most common causes: (1) you forgot systemctl daemon-reload after editing the unit, (2) you enabled the .service instead of the .timer — only the timer should be enabled, (3) the OnCalendar expression is invalid, which you can verify with systemd-analyze calendar "<your-expr>" (this is also where the "failed to parse calendar specification" error comes from), (4) the service itself is failing on first run — check journalctl -u <name>.service, (5) the command in ExecStart= is not an absolute path or relies on shell features like pipes, which require wrapping in /bin/sh -c. Check systemctl list-timers to see when (or whether) the timer plans to fire next.