Differences between Cron and Anacron in Linux explained in detail

If you work with GNU/Linux, sooner or later you will encounter the need to automate recurring tasksBackups, updates, cleanup logs, file synchronizationetc. At that point, the same names almost always appear: Chron and AnacronEveryone mentions them, but it's not always well explained what each one does, how they differ, and, above all, when it's appropriate to use one, the other, or both at the same time.

In this article we'll calmly break down how they work, which files they affect, how to configure them, and what the... practical differences between Cron and Anacron in LinuxYou will see concrete examples, Tricks common tasks (such as launching graphical scripts, managing user permissions, or combining both systems) and also some best practices to avoid messing things up when scheduling critical tasks.

What are Cron and Anacron and how do they generally differ?

In a very brief way, Cron is a daemon that executes tasks at precise times. (specific minute and time), while Anacron is a programmer designed for equipment that is not always switched on. and that ensures that regular tasks are not lost even if the system has been turned off.

Cron assumes the system is available 24/7, which is very typical in servers, VPSs, or production machinesIf the task was scheduled to run at 03:00 and the server is on, it will run. If the server was off or in sleep mode at that time, the task will be missed and Cron will wait for the next scheduled time without attempting to compensate.

Anacron, on the other hand, assumes just the opposite: that the team can to shut down or suspend often (portable(Desktop PCs, home mini-servers, etc.). Therefore, it doesn't work with exact hours, but with periods expressed in days. If there was a "daily" task and the computer has been off for three days, when it's turned back on, Anacron will check what tasks were left pending and execute them when the time comes.

One important difference in philosophy is that Chron is synchronous in the sense of exact time (specific hour/minute), while Anacron works asynchronously with respect to the system clockIt only cares about how much time has passed since the last execution, not the specific time.

How Cron works: daemon, files, and task structure

Cron is a system demon (a background service) that is always active while the machine is powered on. In Debian, Ubuntu, and many other distributions, it runs as the service cron and every minute it inspects a series of files and directories where the scheduled tasks are defined.

On Debian/Ubuntu-type systems, Cron routinely checks these locations:

• / etc / crontab: system master file.
• /etc/cron.d/: additional task files, usually created by packages or by the administrator.
• /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly: directories with scripts that are launched periodically.
• /var/spool/cron/crontabs/: task files for each individual user.

In Debian and derivatives, the file / etc / crontab It includes special entries that call generic scripts to execute the contents of those cron.* directories. For example, a typical line executes everything in /etc/cron.daily once a day at a specific time, as long as Anacron is not taking care of it (we'll see what happens when Anacron comes into play later).

Structure of a Cron line in system files

In system files such as / etc / crontab and the files under /etc/cron.d/Each line with a task follows this structure:

Min Hour Day_month Month Day_week User Command

Example line:

14 1 * * * pepe /home/pepe/bin/tarea.sh > /dev/null 2>&1

In this case, the task is launched every day at 01:14, it runs as the user pepper and the indicated command is the script /home/pepe/bin/tarea.shredirecting standard and error output to / Dev / null so that it doesn't bother you.

User crontab: custom scheduling for each account

Each system user can define their own tasks using the command crontabThis generates and manages individual files under /var/spool/cron/crontabs/ (on Debian), one per user. In these files The user column is not displayed, since Cron knows that everything there must be run like that owner.

• crontab -e: edit or create the current user's tasks.
• Crontab -l: lists the tasks of that user.
• crontab -e -u name: as root, edit another user's tasks.
• crontab -l -u name: lists another user's tasks.

Format of each line in user crontabs:

Min Hour Day_month Month Day_week Command

Some typical examples using crontab -e are:

# Run Nextcloud backup every day at 22:14 PM 14 22 * ​​* * /home/pi/scripts/nextcloudbkp.sh # Run every 3 hours 0 0,3,6,9,12,15,18,21 * * * /home/pi/scripts/nextcloudbkp.sh # Simplified every 6 hours 0 */6 * * * /home/pi/scripts/nextcloudbkp.sh # Monday to Friday at 1:30 PM 30 13 * * 13-5 /home/pi/scripts/nextcloudbkp.sh # Using shortcuts @reboot, @daily, @weekly, @monthly, @yearly @reboot /home/pi/scripts/al_arrancar.sh @monthly /home/pi/scripts/backup_mensual.sh

Meaning of the fields of Chron

In all crontabs, whether system or user-based, the first five fields They have the same meaning. It's essential to understand them well so that tasks are triggered when you want them to be.

Countryside	Description
Minute (m)	Value between 0 and 59. The symbol * It means "every minute."
Time (h)	Range from 0 to 23 in 24h format. * It indicates "all hours".
Day of the month (Sun)	Number between 1 and 31, supports ranges such as 10-20 and lists such as 1, 15, 30 in addition to *.
Month (mon)	Values ​​from 1 to 12, also with ranges/lists and the wildcard *.
Day of the week (down)	From 0 to 7, where 0 and 7 are usually Sunday; English abbreviations are also acceptable: mon, tue, wed, thu, fri, sat, sun.

In addition to numbers and asterisks, you can use expressions like * / 15 to indicate "every 15 units" in the corresponding field (for example, every 15 minutes in the first one) or ranges like 1-5 for "Monday to Friday" in the day of the week field.

/etc/cron.d directory: packaged and system tasks

Directory /etc/cron.d/ It is designed so that system packages or the administrator can define periodic tasks without touching the main file. / etc / crontabEach file you put there represents one or more tasks that Cron checks every minute.

The syntax of each line is the same as in / etc / crontabThat is, it includes the field of userFor example, if you want a Firefox update script to run every day at 10 PM as root, you could create /etc/cron.d/firefox with this content:

0 22 * ​​* * root bash /home/joan/scripts/firefox_update.sh

These files can only be created and edited by someone with administrator permissionTherefore, they are a good way to separate system tasks from each user's personal settings.

Directory cron.daily, cron.weekly, cron.monthly, cron.hourly

The directories /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly y /etc/cron.hourly They are used to place executable scripts that will be released with the frequency indicated by their name.

• cron.hourly: It runs every hour, always managed by Cron.
• cron.daily: It runs once a day, either by Cron or Anacron depending on the configuration.
• cron.weeklyIt is run once a week.
• cron.monthlyIt is run once a month.

If Anacron is not present, the exact time these directories are triggered is marked / etc / crontabIf Anacron is installed, it will normally handle it. cron.daily, cron.weekly and cron.monthlyWhile cron.hourly usually still depends on Cron (This can be changed, but it's the typical setting).

User permission management: cron.allow and cron.deny

By default, in most distributions all users can schedule tasks with Cron. However, if you manage a shared server, you might want to... restrict who can use crontabThat's what files are for:

• /etc/cron.allow: whitelist of authorized users.
• /etc/cron.deny: blacklist of users who are prohibited from using Cron.

The logic is simple: if it exists /etc/cron.allow and there is not /etc/cron.denyOnly listed users will be able to use Cron. If only one exists /etc/cron.denyEveryone except those specified will have access. And if neither of those specified exists, any system user can define their crontab.

Practical considerations when using Cron

There are a number of details Things to keep in mind to ensure Cron tasks run smoothly:

• Always use absolute paths across commands (for example, /usr/bin/rsync instead of just rsync).
• If you need to run complex commands with pipes, redirects, or multiple steps, it's best to create a bash script and call that script from Cron.
• The character % It has a special meaning (marks end of line and beginning of standard input), so if you literally need it, you have to escape it.
• To launch graphical applications from Cron, you need to export a DISPLAY valid, for example:
  env DISPLAY=:0 /usr/bin/xdg-open /ruta/archivo

And very importantly: if the equipment is turned off at the exact scheduled time, The task will not be recovered afterIt's lost and we'll wait for the next interval. Anacron appears just to fill that gap.

How Anacron Works: Philosophy, Files, and Task Management

Anacron is a program designed for To solve the major limitation of Cron on systems that are not powered on all the time: the loss of scheduled tasks when the system is turned off or suspended at the crucial moment.

It is not a demon that is resident in memory all the time. Anacron runs on a one-off basis.: usually when the system starts up, when resuming from sleep, or through a Cron task that calls it periodically (for example, every hour between certain time slots).

When it launches, Anacron reads its configuration, checks which jobs it should have run in the last few days, and verifies if the defined period has passed since the last timeIf it detects that there are overdue tasks, it schedules them with a possible delay and executes them until it catches up.

Anacron Key Files

On a Debian/Ubuntu system, the main elements Anacron's products are usually:

• /etc/anacrontab: central file where Anacron tasks are declared.
• /var/spool/anacron/: directory where the timestamp files for each task are stored.
• /etc/cron.d/anacron: In many systems, a file that makes Cron call Anacron periodically (for example, once an hour between 7:30 and 23:30).
• /etc/apm/event.d/anacron or other startup scripts: used in some distros to run Anacron when mains power is detected or when the system starts.

Furthermore, when Anacron takes control of the system directories, the daily, weekly, and monthly tasks of /etc/cron.daily, /etc/cron.weekly y /etc/cron.monthly They run under its umbrella. The scripts in those directories remain the same, but Cron no longer launches them directlybut Anacron through what is defined in /etc/anacrontab.

Structure of the /etc/anacrontab file

If you open /etc/anacrontab Using a text editor, you'll see that, at the beginning, some environment variables are declared:

• SHELL: command interpreter used for tasks (usually /bin/sh or /bin/bash).
• PATH: paths in which the executables will be searched.
• HOME: default working directory.
• LOGNAME: user under which the tasks are executed (usually root).

Following these variables come the lines that define each task. general structure is

delay period identifier command

Where:

• period: number of days between executions or shortcuts such as @daily, @weekly, @monthly.
• delay: minutes that are expected from when Anacron decides that the job should be executed until it actually launches it.
• identifier: unique name of the task, used to identify it in logs and to name the timestamp file.
• command: command or script to execute, with its full path.

Simple example weekly homework:

7 10   backup.weekly /bin/bash /home/joan/scripts/backup.sh

In this case, Anacron will ensure that each 7 days that script runs. If the computer has been turned off and more than seven days have passed since the last execution, as soon as it Boot or Anacron runs again, they will wait 10 minutes (delay) and then the copy will be released.

Timestamps in /var/spool/anacron

To know when each task was last executed, Anacron creates a file for each job in /var/spool/anacron/The name of each file matches the identifier defined in /etc/anacrontab (for example, backup.weekly, cron.daily, cron.weekly…).

The content of those files is usually just a date in format YYYYMMDDWhen Anacron starts, it compares that timestamp with the current date and the period defined in anacrontab. If the specified number of days or more has passed, it schedules the execution of the corresponding command.

This means that Only the date is taken into account, not the exact time.That's why Anacron isn't used to run things at a specific time, but to ensure that "this task is run at least once every N days."

Useful parameters and options of Anacron

The command anachron It accepts a range of options that are very practical for testing or for controlling how tasks are executed:

• -f: forces the execution of all the work, even if the period has not yet expired.
• -u: updates the timestamps of all jobs as if they had been executed, but without actually running the commands.
• -s: executes tasks sequentially, waiting for one to finish before starting the next.
• -n: immediately executes the relevant jobs, implicitly activating -s.
• -d: does not go to the background; displays messages via standard output (useful for debugging).
• -q: suppresses error messages on standard output, intended for use in conjunction with -d.
• -t fileUse an alternative task file instead of /etc/anacrontab.
• -T: checks the syntax of a task file and displays errors without executing anything.
• -S dir: Use an alternative directory to store timestamps.

If at any time you want force immediate execution For the tasks defined in anacrontab to check that everything is working correctly, you can use:

sudo anacron -f

Advanced options in /etc/anacrontab: random schedules and delays

In addition to the task lines, in /etc/anacrontab Some additional parameters can be defined that affect the overall behavior:

• START_HOURS_RANGE=3-22: limits the time range in which Anacron can run jobs (in this example, only between 03:00 and 22:00).
• RANDOM_DELAY=10: adds a random delay between 0 and 10 minutes to each task, which helps to avoid load spikes launching everything at once right at the start.

By combining these parameters with the periods and delays of each task you can fine-tune the behavior and avoid surprises like CPU or disk working at full capacity in the middle of working hours.

Key differences between Cron and Anacron

Having looked at both separately, it is worth comparing their main characteristics. Cron y Anacron to be clear about what each one contributes.

Cron	Anacron
It is a demon always active in the background.	It is a program that runs on time when it is called (system startup, Cron, scripts).
It allows you to schedule tasks exact minute and hour.	Works with periods in days (daily, weekly, monthly, every N days), without specific times.
If the computer is turned off when a task is scheduled, that execution is lost.	If the device was turned off, when it was turned back on complete the overdue tasks where appropriate.
Any user can schedule tasks (except for restrictions with cron.allow/cron.deny).	Normally, only the administrator (root).
It is ideal for 24/7 servers or systems where the clock is reliable.	It is ideal for laptops, desktops, and equipment that frequently shuts down.

In many modern distributions, especially Debian and its derivatives, Do they both come pre-installed, or is it recommended to install them together?Cron handles time-sensitive tasks, user jobs, and directors like cron.hourly, while Anacron takes responsibility for cron.daily, cron.weekly, and cron.monthly to ensure that system maintenance tasks are not lost even if the computer is not always powered on.

When to use Cron, when to use Anacron, and when to combine them

A very practical way to decide is to think about the type of machine and the type of task you want to automate.

• In a server that operates 24/7 (web, database, email, etc.), it is normal to rely almost exclusively on CronYou can install Anacron if you want, but on a server that is never turned off it doesn't add much.
• In a desktop or laptop Since it turns off and on every day, the sensible thing to do is to use Chron + AnacronCron for very specific tasks (running something every 15 minutes while the computer is on) and Anacron for "daily", "weekly" or "monthly" maintenance tasks that you don't want to miss if the PC was off when it was due.

Practical rules which usually work well:

• If you need exact executions At the hour (for example, a script that runs daily billing at 23:58), use Cron.
• If it's enough for you that something happens at least once every X days (for example, rotating logs, deleting temporary files, regenerating indexes), use Anacron or have your scripts in cron.daily, cron.weekly and cron.monthly handled by it.
• On Debian servers, it is common for tasks installed by packages to be located in /etc/cron.daily and similar. If Anacron is present, it will ensure that these tasks are executed even if your server experiences unexpected outages.

Practical example with Anacron: daily backups even if the computer is not always on

Imagine you want to have a daily copy of an important fileBut your computer shuts down every night, and you don't know exactly when you'll turn it back on. Anacron is perfect for this.

Suppose you have a file /home/usuario/prueba.txt and you want to save daily copies with the date and time in the name. You can create a small bash script, give it execute permissions, and then add a line to /etc/anacrontab run it once a day with a small delay after the system starts.

Flow typical work:

• You create the script /home/usuario/prueba.sh that copies the file with a date and time suffix.
• You give it execution permissions with chmod 700 prueba.sh.
• You test the script manually to confirm that it does what it's supposed to.
• Edits /etc/anacrontab and you add a line like this:
  @daily 1 somebooks /bin/bash /home/usuario/prueba.sh
• You restart or force Anacron to check that everything is running correctly.

From that moment on, once a dayOr, as soon as the computer powers on if it was unable to run the job the day before, Anacron will launch your script, wait one minute (delay=1) and generate a new versioned copy.

Other related tools: at and systemd timers

Although Cron and Anacron are the stars of recurring automation in Linux, there are other tools that should be on your radar.

On the one hand you have atdesigned for programming tasks that are executed only once at a specific time. It's ideal when you want to say something like "run this command tomorrow at 10:15 and forget about it."

• A basic example of restarting at a specific time:
  at 10:15
> reboot
> ^D
• Or something more elaborate, with a service stoppage, waiting, and restart on a specific day:
  at 12.12.2106 21:23
> /etc/init.d/apache stop
> sleep 600
> /etc/init.d/apache start
> ^D

Jobs at are stored in /var/spool/cron/atjobs and you can list them with until o at-l, in addition to deleting them with atrm.

On the other hand, in modern systems with systemd There are also the systemd timersThese tools allow you to replace (partially or completely) Cron and Anacron by defining .timer and .service units. They are a very powerful option, but somewhat more complex to configure; if you already master Cron/Anacron and want even finer control over dependencies and service states, they are worth exploring.

In practice, for most administrators and advanced users, combining Cron, Anacron and at It offers a sufficient range to cover almost any automation need without having to complicate your life from day one with systemd timers.

With all this on the table, you now have a pretty complete picture of how Cron and Anacron share the automation work in LinuxCron is responsible for triggering processes with Swiss-watch precision as long as the system is up and running, while Anacron runs in the background checking what has been left undone when the machine has been turned off, ensuring that daily, weekly or monthly maintenance tasks are not lost even though the equipment has a longer lifespan than a classic server.