# Scheduling Jobs: Cron vs. Anacron vs. Systemd

1. Today, you generally have three choices for a time-based system scheduler: “Cron”, “anacron”, and “systemd”. There is a lot of information out on the web about these, so here I shall just summarize the basics from a practical standpoint to answer the question “which scheduler/timing system should I use?”

2. Cron” is the traditional timer. It is available everywhere, and tried, tested, loved, and it just works most of the time for most people.

BUT, jobs only run when the machine is on during their scheduled time. So, for example, if you have a cron job schedule to run daily at 4 am, it will only run if the machine is on at 4 am. Under all but extraordinary circumstances, this is probably not going to be an issue for most servers. However, for desktops and more particularly, laptops, this might be a problem: if your laptop is closed/suspended during the scheduled time, then the job simply will not run. This makes relying on “Cron” for personal backups less than entirely satisfactory, especially in the case of jobs that run on a daily or coarser granularity basis (if your jobs run every hour, chances are pretty good you are going to hit the timings several times day). This is where “anacron” comes in.

3. anacron” is the scheduler to use for laptops, desktops, or any machines that are frequently turned off. If a job scheduled by “anacron” does not run because the machine was turned off during its scheduled time, then it will run once the machine comes online again.

In contrast to “Cron”, “anacron” can only be run at no less than a daily granularity (i.e., no hourly backups). Furthermore, by default “Cron” jobs can be scheduled by both root as well as normal users, while “anacron” is only really meant to be run by root though normal users might get this ability based on configuration.

4. systemd” timers are the hot and trendy way to set up scheduled jobs. It is the one that all the kids are using nowadays. It is quite a bit more complex to set up than either “Cron” or “anacron” (requiring creation of a timer unit and a service unit file for each job, as opposed to requiring just a simple entry in a text file), and takes a little bit more of systems know-how to use.

What do we get for all this pain and palaver?

The biggest benefit is consistency in execution context. A major bugbear with “Cron” and “anacron” is how your jobs would be run in an environment that is not quite the same as the shell, which mean that not only was there a much greater chance of things going awry due to, e.g., different variables, paths, etc., but made debugging a major hassle as you could not isolate/test the scripts in the same context they would be executing in.

There are other numerous little benefits, including (automatic system) logging of jobs, and really nice control over jobs, through various “systemctl” subcommands such as: “status”, “start”, “stop”, “reload”, “restart”, “enable”, “disable”, “renable”, etc.

In so far as the “Cron” vs. “anacron” trade-offs described above, “systemd” timers offer the best of both worlds: i.e., ability schedule jobs as a user, specify sub-day granularity (e.g., hourly, or every four hours) , and run after coming online if a job was missed because the machine was off (by specifying “Persistent=true” in the “[Timer]” section of the timer file).

5. In a subsequent post, I will provide an illustrative recipe on how to setup a “systemd” job.

6. References:

Share