Love systemd timers

Perceived advantages of systemd timers

• Many commenters have migrated most or all cron jobs to systemd timers, especially for backups and maintenance tasks.
• Timers can be “persistent”: if the system is down at the scheduled time, the job runs once on next boot.
• Integration with systemd units gives per-job logging via journalctl, easy manual triggering (systemctl start …), and consistent environments between timers and services.
• Features like RandomizedOffsetSec= and host-stable jitter help avoid “thundering herd” load spikes across many machines.
• Time specification supports time zones and richer calendar expressions than classic cron.
• Some praise the security/sandboxing features available on the service side (namespaces, capabilities, random UIDs), seeing them as simpler than containers for many daemons.
• Socket activation is highlighted as powerful for lazy-starting services and sandboxing network access.

Comparisons with cron (and variants)

• Cron is seen as simpler for trivial “run every N minutes” jobs and very tangible (crontab -e, one line, done).
• Others find cron notoriously brittle: different environment, $PATH issues, output disappearing unless explicitly captured, and tricky debugging.
• Some note cron already has extensions like @reboot, anacron-style catch-up, RANDOM_DELAY, and CRON_TZ, arguing systemd’s advantages are smaller than claimed and not universal across cron implementations.

Syntax, configuration, and tooling

• Debate over systemd unit syntax: some consider INI-style files clean and minimal; others find them ugly and wish for YAML, XML, or TOML.
• Misconceptions are corrected (e.g., spaces around = are allowed; Environment= can hold multiple variables).
• NixOS users like defining units declaratively in Nix, with type-checking and composition; critics find that representation uglier and miss explicit [Unit]/[Service]/[Timer] sections.
• Timers requiring a separate .service and .timer file are seen as both flexible and annoyingly verbose.

Reliability, complexity, and criticisms

• Several comments praise systemd’s robustness and documentation compared to old init scripts and cron.
• Others recount serious bugs (e.g., a logrotate timer silently never running) and accuse systemd of high accidental complexity and poor maintainer responsiveness to edge cases.
• Broader architectural concerns: systemd as an ever-growing monolith, “embrace and extend” of existing tools, and fear of vendor lock‑in.

Ecosystem, portability, and alternatives

• Some admins prefer or require cron on BSD, Alpine, or non-systemd Linux, or use alternative schedulers (mcron, custom job runners).
• General consensus: timers are great on systemd systems, but cron remains valid, especially where systemd is absent or unwelcome.