How-To Guides and Blog

How To Schedule Future Tasks In Linux

NBH Support
No Comments

As a system administrator, the most important thing is been able to run a task or set of tasks at a set point in the future. This typically happens in a production environment where jobs are meant to be executed simultaneously or at some set point in the future. This helps to prevent you from manually running tasks, as these can be set to be a one-time job or run periodically based on a predefined time schedule. For example, you can schedule a backup to run daily, weekly, or monthly to help improve performance and reduce the manual effort in the organization

The Linux Operating systems have these built-in daemons for scheduling recurring and one time jobs—crond and atd. The cron command is used to run recurring jobs— that’s jobs you want to execute every time in a predefined timeframe while the at command is used to run a one-time job in the future–those are jobs you want to run over the weekend but doesn’t have to be recurring every week. There is another command called the anacron, which is similar to the cron command. There are both used to run recurring jobs but slightly different in their functions. In this article, we will be looking into details of the differences in both commands.

Meanwhile, this article is to help you understand how to schedule a one-time and recurring task in Linux to perform routine backups and general maintenance on your server.


One of the available options for Linux system administrators is the at command to help them schedule a one-time future task. The at command operates on a daemon called the atd, and it is accompanied by other commands such as the atq, at, and many more. In some Linux system like RedHat based systems, the atd daemon will be installed by default while others will have it installed before they can make use of the at command to schedule jobs. To go about this, run the yum install at on Redhat-based systems or apt-get install at on Debian-based systems.

Once the program is installed, you must start and enable the atd daemon with root privilege to allow it to start automatically at system boot. This can be done by running systemctl enable – -now atd.service

To schedule new a job, the command follows the syntax as at <TIMESPEC>. This will read your instructions from the stdin. You can as well write all your instructions on a script file and make use of the input redirection key to point to the script file, which will be executed using the at command. For example, at now +5min < myscript. This saves time when typing your commands on the terminal.

In a situation when you choose to type your command on the terminal, once you type in the command, the at shell will open for you to type in your instructions. After entering your set of instructions, press the Ctrl +D to finish your input.

Let’s give this a practical example.

You can see from the command above; I set the system to restart my network service in 5 minutes. In the second command, I kept my command in a script, and I made the command to execute the command from a file script. Note that, you have to make the script file executable by using the chmod command as seen above

The <TIMESPEC> can be specified in so many forms that allow the administrator to have a free-form way of expressing how the job should be run.

The time can follow in this format as 12:00 pm, 16:40, and an optional date or number of days in the future.

The following are most used similar timespec

Now + 5min

Now +6 weeks

Teatime tomorrow (teatime means 16:00)

7 pm July 5 2019

Noon +6 days

For clarity, let’s give an example using one of the following timespec


To get an overview of the job to be executed, you use the at –l or the atq command. Using any of the commands will present you the job to be executed with their job number

Running the command will give you the following outputs, as seen below. Don’t worry; I will be explaining each column for a better understanding of your output

The first column from the output shows the job number.

The second column shows the date and time the job is to be executed

The third column shows the queue for the job.

The fouth shows the owner of the job

Please note that regular users can see and manage their own jobs, but the root user has all the privileges to view and manage all jobs.


Apart from inspecting the job to run, you can as well examine the instructions that will be run once the command is executed. To go about that, use the at – c, followed by the job number. The output will show the environment being set up to reflect the environment of the user who created the job and the time it was created, followed by the actual command that will be executed.


To remove jobs you no longer want to execute; you use the atrm command alongside the job number. This command is useful when there is a need to stop a mail from sending at a specified date.

Let’s see how this works by removing one of the jobs created earlier


Unlike the at command, which runs a one-time task, you can run a job to reoccur depending on the time specified using the cron command. The cron command is a useful tool for Linux system administrators to run routine system maintenance and server backup. The cron service (daemon) runs in the background and regularly checks the /etc/crontab file, the /etc/cron*/ directory, and /var/spool/cron directory to see if any job needs to be executed.


Regular users can use the crontab command to manage their own cron jobs. These crontab commands can be used to create/edit, list, remove cron jobs. Though each user has their own cron files, which are files in the /var/spool/cron/crontab. This file is not supposed to be edited directly, so you need the crontab to set up your own cron file. Though, only the root has access to edit this configuration file

Let’s look at the various ways in which the crontab command can be used

Crontab –l: This will list jobs for the current user

Crontab –r: This will remove all jobs for the current user

Crontab –e: This will create or edit jobs for the current user

Crontab <filename>: This will remove all jobs and replace with jobs read from the file specified

Please note that the root user has the –u option to change the job of other users. It is not recommended to use crontab to manage system jobs.

Now let’s get down to knowing how to create your own jobs and the structure it should follow, but you also have to understand all I have said to be able to structure your job.

When editing or creating your job with the crontab –e command, the command opens the vim editor by default, except it has been configured to open with something else.

The jobs that have been edited will have one job per line. Empty lines are allowed, and all comments must be preceded with a hash sign (#).

Individual jobs consist of 6 fields showing the time a job is to be executed as well as what will be executed. When all the first five field matches with the current time it is programmed to be executed, the instructions in the 6th field will be executed

The field follows the pattern as seen below

Minute: The First field is specified in minute ranging from 0-59

Hours: The Second Field is specified in hours ranging from 0-23

Day of the Month: The Third field is specified in days in a month ranging from 1-31

Month: The Fourth field specified the month which ranges from 1-12 or Jan, Feb, Mar, Apr, etc

Day of the week: The Fifth field are the days in a week ranging from 0-6 where Sunday=0 or 7 or Mon, Tue, Wed, Thur, Fri, Sat, Sun

Command: The Sixth field is the actual command to be executed

Viewing the configuration file- /etc/crontab of cron jobs from the command line, you would see something that looks like this on RedHat based Operating systems

This might look quite different on Debian Operating systems

Please note that when the day-of-week and the day-of-month are set, the command will be executed only when both timespec match. This is why it is important to set both the day-of-week and day-of-month to (*-which means don’t care)


You can indicate your timespec using the following operators (*, /, -). One or two of these operators can be combined to specify when and how your cron jobs will be executed. Below are how these operators are used

x-y: Which means range. That’s to say, the time specified should range from x to y. For example, when the minute time is specified in range, such as 7-9. It means the command should run at 7 minutes, 8 minutes, 9 minutes past the hour specified

x,y: This means list. They can also include range as well. When the minute
is specified as 7,9, it means the command should run at 7, 8, 9 minutes past the hour specified

*/x: This indicates an interval of x. when specified as */9, it means the command should run every 9 minutes.

Don’t worry; we will be looking at some practical examples of how all these works. First, let’s schedule a job to run every minute

The job above is scheduled to print the current date every minute and redirect
the output to a file. Note that if a file is not specified in the crontab command, the output will be redirected to the mail of the user who created the cron job.

You can also specify to execute commands at some specified minute, month, and year. Let’s give that a try

We have scheduled a cron job to run every two minutes, from 1 am – 2 am on the 27th of October. The 27th of October happens to be on Sunday from my time. We also want this output to be sent to a file. This means that every two minutes, from 1 am-2 am, the cron job will keep writing to the file.

Please note that when the day-of-month and the day-of-week are both set to a specified day, the command will only execute only when both commands match else the command will keep waiting for a day when there will be a match. This happens to be the most common errors made by newbies. To clear this issue from occurring, you have to specify the * sign.

Instead of having to type your commands on the crontab file, you can schedule your jobs from a script. This is very useful in a production environment when you have to be checking disk, CPU usage daily, or when running a company’s backup.

The command above will execute a script file that will check disk usage every minute. This is just a simple guide on how to execute a script file from the crontab file. You can as well choose to make the output sent to your email or an external file by using your output redirection symbol as seen below

Many administrative tasks are performed hourly, daily, weekly, or monthly basis. This made life easy for administrators as most of these tasks can be run without having to create a separate crontab file.

If you have to schedule a backup of this type, you don’t need to create a crontab file for it; instead, place the script file that performs those tasks in one of the following directories.





For example, the script you want to execute for an hourly basis, place it in the /etc/cron.hourly, and the same applies to others. If you have the script already in a file, you can go ahead to copy it to that directory. If you have no script, you can as well create a file inside the directory, as seen below, and write your script in it.

Please note that the script file must be made executable before the system can execute it as a script. This can be done by writing the chmod +x <ScriptFilename> on the command line.

Cron is excellent in scheduling tasks in Linux, but it has one weakness. Cron loses its jobs when a server is down or turned off. So for cron to be able to execute your job, the server or the system has to be up and running. But there is a solution to this — another tool called anacron, which offers a comparative advantage over cron. The anacron helps to execute jobs at a guaranteed interval.
This means that the anacron tool will still run its task even when the system or the server is down.

So we will be looking at how to set up jobs using anacron, but first, let’s understand the contents in the /etc/anacrontab file. The file holds four fields which determine how your jobs are to be executed

Period-in-days: This field shows how many days the job is to be executed

Delay-In-Minutes: It is the amount of time the cron daemon should wait before executing the job

Job-Identifier: It identifies the command to run. Its main job is to identify the jobs in messages, log files for special execution

Command: This is the actual command to be executed

The nice command runs the command at low priority. The run-parts command is a cron tool used to execute each file specified in the directory

Now let’s execute a task to run daily check on your disk usage of our sever. As seen in the /etc/anacrontab file, you can insert your command below the file.

If the system is down, anacron will execute the command 15 minutes after the system is powered on.

It is good to know that anacron is not a service that needs to be configured directly. The presence of cron.daily, cron.weekly, cron.monthly, cron.hourly has taken away that aspect. All you need is to drop your script in of the directories and change the delay to your choice and have the anacron execute your job for you.

There are various options you can use with anacron. You can run the anacron –T command on the command line to check any syntax error present in the anacron file.

The anacron –d command will run the anacron job on the foreground


We were able to go through how to schedule future tasks using at, cron, and anacron command. The at command can only schedule a one-time future task while the cron and the anacron can schedule a recurring job. We also discuss the comparative advantage anacron offers compared to cron, which comes with how both tools handle tasks when there is a shutdown of your server or system. With anacron, jobs will still be executed upon system boot, which is not the case with cron.

Please leave a comment in the comment section if need be to add or remove from
this article