I notice that on Debian related systems, system level crontab scripts in /etc/cron.hourly, /etc/cron.daily... are being gradually decommissioned in favour of systemd timers. Eg:

$ cat logrotate

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0


I presume that one goal is to gradually decommission cron and anacron. (See note 1)

For me a critical use case of cron is user defined crontabs (crontab -e) which allow a user to schedule their own jobs to run as their own user without requiring sysadmin privileges.

Are there any features in systemd, current or planned, which allow non-admin users to schedule repetitive tasks?

Note 1:

Weakening the earlier statement somewhat I've not found any particularly good discussions except those badmouthing cron and singing the praise of systemd timers. I've found no evidence that this direction of travel has been handed down by the gods of Linux distribution. However I do notice it as a direction of travel. Therefore this statement is only based on the idea that if this is a direction of travel and with time I would expect most / all packages to eventually go the same way and make one system (cron) redundant.


1 Answer 1


Users can set up systemd timers, basically by creating a service and timer in ~/.config/systemd/user and enabling the timer.

There are two main features which are lost by switching from user-defined cron jobs to systemd timers (whether that’s good or bad depends on the situation):

  • systemd services don’t email their results;
  • systemd user timers only run when the user session is active, unless the user is configured to linger (which is something the administrator needs to do).

Using systemd timers adds a number of possibilities compared to cron jobs; for example the time specification is more expressive than cron’s, and timers can be configured to fire with additional requirements such as “only when a specific VPN is up”. (Of course all these niceties can be written in cron jobs too...) I also find systemd timers nicer to manage than cron jobs: it’s easy to see what a timer’s status is and the next time it will fire.

In Debian, the pattern you’ve seen is used to avoid having repetitive tasks run twice, once by systemd and another time by cron or anacron (for whatever reason). It doesn’t mean there’s a general goal to decommission cron or anacron.

  • If I were being argumentative I would point out that simply not writing a systemd timer at all would avoid them "running twice". Adding a systemd timer then adding a further override if clause in the cron script suggests a certain direction of travel maybe? May 7, 2019 at 13:47
  • It does, yes, on the part of the corresponding package’s maintainer. It doesn’t suggest a general goal (which is all I’m saying). May 7, 2019 at 13:48
  • Okay so it's fashion (or good practice) rather than master design. That is fair enough. May 7, 2019 at 13:50
  • 1
    For the logrotate case specifically, see #858021. May 7, 2019 at 13:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .