The purpose of this article is to review the three approaches to working with crontab. The first is the mainstream proposed best practice of using crontab -e. The second is to edit the crontab file directly. The third method is to use your text editor to create files for crontab and then sync them using the crontab command. This article will review each method and explain their pros and cons. The basics of working with crontab entries can be found at the following sites:
- Crontab’s man page at https://linux.die.net/man/5/crontab
- Admin’s Choice page at http://www.adminschoice.com/crontab-quick-reference
Method 1: Editing Cron Jobs using Crontab -e
This first method of working with crontab is the most popular approach. Each user has a crontab file, the contents of your user account can be displayed using:
$ crontab -l
You can edit the crontab settings by issuing the command:
$ crontab -e
In addition to the user’s crontab file there is also a system crontab file. The system crontab requires the additional setting of assigning a user for whom to use to execute the command. This file can be accessed using:
$ sudo crontab -e
General best practice here is to use the lowest level of credentials needed for running a given command or script so the system crontab file should only be used when absolutely necessary.
Issuing the crontab -e command will open or create the crontab file. This method opens a temporary crontab file located in /tmp (Stackexchange.com, 2015). The file will be opened for editing using your default editor. If your user account does not have one, crontab will display a list of editors, allowing you to select one for use (DigitalOcean, 2017).
Pros:
The benefit of using this method is that cron will check your temporary file for mistakes prior to installing it with the original. Should a problem occur from your changes you will receive a prompt with an error message that explains the cause and asks if you’d like to retry editing it. Any syntax mistakes will stop all jobs from running.
Cons:
The downside to this method is that it leaves users with a false sense of security. The user crontab files are stored in /var/spool/cron/crontabs under the user ID. This directory might not be backed up or it could become disassociated with your login. In either case your jobs wouldn’t run.
Method 2: Editing Crontab Directly
This next method is not popular nor is it advisable. Crontab files can be edited directly using your text editor of choice. For this method, you would need to access the crontab file and open it for editing directly. There are two different crontab files, each located in a different area. The two are:
- The user crontab file located in /var/spool/cron/crontabs
- The system crontab file located in /etc/cron.d
The difference between the user crontab file and the system crontab file is that the system crontab file requires an added entry for the user executing the script and allows for jobs to be run with root authority. In order to edit the crontab files directly, you will either need access to root or your account will need sudo privileges.
Pros:
The only real benefit to using this method is ability to work with the text editor of your choice. By default running crontab -e opens the file in vi. This can be easily changed by setting your environment variable for the editor of choice with the command:
$ export EDITOR=<editor_name>
Cons:
There are plenty of cons that should be carefully considered before choosing this approach. The first is that you lose the protection of syntax checking and cron giving an error message should something be wrong with part of the file–this will lead to your jobs not running as expected. Second, you won’t receive any warning from cron if the file is being edited in another session, though you may receive an OS level warning. This means the file can be corrupted through direct editing. Another con is that again, you won’t have a backup file of your cron jobs should you need one.
Method 3: Using Custom Crontab files
This third method of working crontab leverages the benefits of the first method while overcoming the problems of both methods one and two. With this method your cron jobs are stored in a text file in a location that is preferably backed up with other important files. The best practice here is to name files appropriately, such as crontab.myfile. This file may be a new file or you can pull down the current cron jobs and edit them as needed. When you’re finished with the file, uploading it into cron is done by running the crontab command. The commands for performing these steps are shown below.
To capture the current cron jobs for editing run:
$ crontab -l > crontab.myfile
To upload your file’s contents into crontab run:
$ crontab crontab.myfile
Pros
The benefits of this method include preventing problems from cron losing association with the user ID, having a backup file, and because you’re using cron to install the jobs, you have the added benefit of leveraging cron’s syntax checking, which will notify you of any errors found, and give you the opportunity to correct them.
Cons
This method can be troublesome if you edit your crontab files frequently and keep copies of each change without a good naming scheme. It could be easy to confuse which file is the correct, current file for use. The other issue here is that unlike using the first method, the user is responsible for installing the jobs after creation. If you forget to upload your file contents into cron, your system will continue using the previous jobs. This is in contrast to method 1 where the upload is automatic upon closing the file.
References
Both, D. (2017, November 06). How to use cron in Linux. Retrieved from https://opensource.com/article/17/11/how-use-cron-linux.
Stackexchange.com. (2015, April 20). Shall I save my crontab file in /tmp? Retrieved January 4, 2019, from https://unix.stackexchange.com/questions/197504/shall-i-save-my-crontab-file- in-tmp.
DigitalOcean. (2017, November 22). Contents. Retrieved January 4, 2019, from https://www.digitalocean.com/community/tutorials/how-to-schedule-routine-tasks-with-cron-and-anacron-on-a-vps.
Admin’s Choice. (2018, October 23). Crontab – Quick Reference. Retrieved January 4, 2019, from https://www.adminschoice.com/crontab-quick-reference.
Vixie, P. (n.d.). Crontab(5) – Linux man page. Retrieved January 4, 2019, from https://linux.die.net/man/5/crontab.