Linux Mint – Setting up cron jobs

install phpMyAdmin On CentOS 8

There may come a time when you might want a task to run automatically at particular intervals, without your involvement being needed. Linux features cron, a utility for doing just that. A cron task is called a job, so you may hear the combined term, cron job, in the Linux community. Cron may seem rather complex at first, but it’s surprisingly simple once it is broken down.

The first thing to note is that each user has his or her crontab, which is the term used for the configuration file that contains one or more cron jobs. By default, no user has any jobs created; thus, each user has an empty cron job. Inside a user’s crontab, you place cron jobs in their own separate line, with a specific command to be run. This means that each user may have their own tasks to be automatically completed at specific times. For system administration purposes, administrators will often use the root user or a dedicated service account to run cron jobs.

To get started with this concept, try the following command under your own user account:

crontab -e

If this is the first time that you are running the preceding command, it may ask you to choose a text editor. For those just starting out, nano is probably the safest bet. Then, you should see nano open an empty cron file for you to edit. Although the file is considered empty, you may still see a bit of text in the file. Upon further inspection, you’ll notice that each line begins with a hash character (#), which means that it’s a comment that is ignored by cron. As each line begins with a hash, every line in the file is ignored. The included lines are simply pieces of instructional text that provide you with some important information regarding how cron works. Feel free to read it; then, we’ll summarize it here.

First, notice the sample command provided in the file. This is a sample cron job line but is commented out like the other lines, so it won’t be used by cron. However, it is a good example to start with. The line from a sample Mint PC used for the creation of this tutorial is shown as follows:

0   5     *     *     1     tar -zcf /var/backups/home.tgz /home/

In the preceding example, we see a series of characters that are separated, followed by a command. The first section of a cron job, a 0 in this example, refers to the minute that the job will happen. Since 0 is used here, the minutes section is :00. The next section is the hour; 5 in this case. Therefore, we can gather so far that the command will be run at 5:00 a.m. (cron uses military time). The third section refers to the day of the month, but we have an asterisk ( *) here. The asterisk, in this case, means that it doesn’t matter what day of the month it is; just run it. Next, we have a section for the month; this is another asterisk. In this example, it means we don’t care which month it is. So far, we have a command we want to run at 5:00 a.m., regardless of the date. The fifth field is set to 1 in our example, and this field represents the day of the week. Since we have 1 here, it means that we want to run the command on Mondays. (Sunday would have been 0). Finally, the command that we want to execute is listed. If we put it all together, this line means we want to run the following command every Monday at 5:00 a.m:

tar -zcf /var/backups/home.tgz /home/

As another example, if we wanted to run the emailstatus command (a made-up command for our example) every Friday at 11:30 p.m., we would use the following command line:

30   23     *     *     5     /usr/local/bin/emailstatus

Notice how we wanted to run the emailstatus command, but the second example shows the entire path to the emailstatus command. This is important. While using the command by itself may work fine, there is no guarantee that it will. Typing out the entire path for the command as well as its name is considered to be the best practice with practice when using cron. If you don’t know the entire path to the command you want to use, try the which command to find out. For example, you wanted to find the entire path for the following apt command:

which apt

The output from which apt would be as follows:


Therefore, apt is located in the /usr/local/bin folder, and the output includes the full path for apt, which you would be advised to include should you want to include it in your cron job. This rule also includes scripts, meaning that if you want to use a script in your cron job (and you certainly can) you should include the full path to the script, as well as full paths inside your script. The reason for this is because some distributions may not recognize the same paths as others, which may cause your cron job to fail.

To create a cron job, simply type it out on its own line after using the crontab -e command to open the file. When finished, save the file. In the case of nano, you can save the file by pressing Ctrl + O and then you can exit the editor by pressing Ctrl + X.


You can actually edit the crontab manually without using the crontab command, but that’s considered a bad practice and may not be respected by cron when it runs. The crontab command is the preferred interface between you and adding new cron jobs.

Our examples so far have been to add a job to run as your own user account. Perhaps, instead, you may want to run a command as the root. To do so, you would use the crontab -e command, but prefix it with sudo. If you run the crontab -e command with sudo, you’re essentially running it as root. This would therefore result in your editing root’s crontab, instead of your own.

To list your cron jobs, the crontab command becomes crontab -l. With the -l flag, the contents of your crontab will be presented on screen, allowing you to view the file for errors or simply see which jobs you have scheduled to run. If you prefix crontab -l with sudo, you’ll see root’s crontab instead.


Be very careful when using the root for your crontab. If you can help it, consider creating a dedicated user to run the command, and give sudo privileges for that specific command to this user account, bypassing the password. If the cron user account you create ever becomes compromised, you can reset its password without affecting the root.

Running cron jobs on your system can help you automate many things, such as package updates, temporary file cleanup, backups, or even sending automated e-mails that contain important information about the system, such as available hard disk space, to administrators.

Comments are closed.