Love systemd timers

Original Article ↗ Hacker News Discussion ↗

Systemd timers are emerging as a popular alternative to traditional cron jobs for scheduling tasks on Linux, praised for features like persistent timers, better logging via journald, socket activation, timezone support, and easier integration with modern tools and distributions such as NixOS and Podman. Critics counter that systemd’s unit syntax, multiple-file model, and expanding scope add complexity and create obscure failure modes, and some prefer cron’s simplicity and long track record despite its quirks. Overall, many users report gradually migrating scheduled jobs to systemd timers for reliability and observability, while others remain wary of systemd’s design philosophy and monolithic growth.

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.