Location of the crontab file
as many (most?) others, I edit my crontab via crontab -e , where I keep all routine operations such as incremental backup, ntpdate, various rsync operations, as well as making my desktop background christmas themed once a year. From what I’ve understood, on a fresh install or new user, this also automatically creates the file if it doesn’t exist. However, I want to copy this file to another user, so where is the actual file that I’m editing? If this varies between distros, I’m using Centos5 and Mint 17
2 Answers 2
The location of cron files for individual users is /var/spool/cron/crontabs/ .
From man crontab :
Each user can have their own crontab, and though these are files in /var/spool/cron/crontabs , they are not intended to be edited directly.
The key words there are «they are not intended to be edited directly», so this answer is incomplete without Celada’s command below, which provides a safer answer to the «copy to another user» portion of the question. If people get in the habit of directly editing crontabs without submitting them through the crontab command, they forego a lot of sanity-checking the command provides.
@MontyHarder I agree «they are not intended to be edited directly» but what if there is a need of it, like there is a need to make an entry in the crontab via a bash script. you have to use the exact file, I don’t think any external interface will help in that case, correct me if I am wrong.
@PrabhatKumarSingh You still shouldn’t directly edit the file. If you read Celada’s command below, you’d have seen an example of how a script could manipulate a crontab file without directly editing it. man crontab explains how this works.
heemayl is correct about the location of crontab files on Linux, but it might be different on other operating systems and «theoretically» is could also be in a different location on Linux. Essentially, when a special interface is provided to access the files, you should use it. This will ensure that cron gets to check the files before installing them, makes sure the files have the permissions it needs them to have, etc.
Therefore you should copy a crontab from one user to another using that interface, like this, not by accessing the files directly.
There are many good reasons why crontab files should not be directly manipulated by anything other than the OS itself. This is a far better solution. I really think it needs to be incorporated into the official answer.
@MontyHarder There isn’t really an «official» answer. There is the answer the person asking chose as personally useful to him/her (the one with the checkmark) and the answer the community chose (with the most upvotes). In short, you have 15 rep, you can suggest this is the right answer by upvoting it. Also, if you want to suggest improvements to the other answer, you need to comment on that answer—otherwise, its author won’t be notified of your comment.
The corollary of this answer is that one should redirect the output of crontab -l to a file, move the file to the other system, and pipe it to crontab . Or maybe even do it directly ( crontab -l | ssh $remote_host crontab ).
«when a special interface is provided to access the files, you should use it.» Imagine every application provided a special interface for editing config files instead of just exposing them through the fs, though. That would be quite the annoyance to keep track of.
As the original asker, I think I should perhasp weigh in on this: The accepted answer was chosen on the basis of my question in its literal sense; the location of the file. My intentions for that file is irrelevant. I don’t think editing in the additional info changes the answer, but it might be considered superfluous.
The 5 places cron jobs are saved
Cron has been popular for decades because it’s easy to use and available everywhere. The downside to this flexibility is that cron job maintenance and debugging can be a real headache. In this guide we explore five different places you can find cron jobs on your server.
The user crontab file
In Linux, each user has their own crontab that can be used to schedule jobs that will be run as that user. You can view, update and delete a user crontab file using the crontab command.
Viewing your user crontab
$ crontab -l 0 9 * * * /var/cronitor/bin/water-the-plants.py 0 7 * * 6 /var/cronitor/bin/take-out-the-garbage.py Viewing another user’s crontab
$ crontab -u tstark -l 0 0 * * * /jarvis/reboot-arc-reactor If your server has a lot of users it could be challenging to find the right one. If you can see the job details in your cron logs, the username may be included. In the example below you can see the ubuntu user running the database backup script:
Aug 5 4:05:01 dev01 CRON\[2128\]: (ubuntu) CMD (/var/cronitor/database-backup.sh) To update a user crontab, use crontab -e . The cron files themselves should not be updated directly. Using crontab -e will validate your changes and signal cron to reload your file.
The root user crontab
Like any other user, root has a user crontab. Essentially the same as any other user crontab, you are editing the root crontab when you run sudo crontab -e .
Jobs scheduled in the root user crontab will be executed as root with all of its privileges.
In /etc/cron.*
If your system has /etc/cron.hourly , /etc/cron.daily , /etc/cron.weekly , and /etc/cron.monthly directories, these can be used to schedule jobs by copying or symlinking a script or command.
In distributions like Ubuntu, you can see when these scripts will be invoked by looking for lines in /etc/crontab :
$ head /etc/crontab 7 * * * * root cd / && run-parts — report /etc/cron.hourly 5 23 * * * root cd / && run-parts — report /etc/cron.daily 5 23 * * 7 root cd / && run-parts — report /etc/cron.weekly 5 23 1 * * root cd / && run-parts — report /etc/cron.monthly System crontab file
The original and still commonly used way to schedule system-wide cron jobs is by adding entries to the crontab file /etc/crontab .
Writing to /etc/crontab requires admin privileges and jobs scheduled here can be run as any user. To specify the user, provide a username as the first word after the schedule expression. In this example, the job will be run by user dataproc:
$ tail /etc/crontab * 0 * * * dataproc /var/cronitor/bin/database-backup.sh System drop-in directory /etc/cron.d
Another common way to schedule system-wide cron jobs is by adding a crontab file to /etc/cron.d .
Like jobs scheduled in /etc/crontab, writing to /etc/cron.d requires elevated privileges and the first word after the expression of each cron job must specify which user will run the job.
Tip: For installers and scripts, adding a file to /etc/cron.d is a much cleaner option than adding entries to crontab files.
Understanding /var/spool/cron
When individual user crontabs are edited using crontab -e , the crontab files themselves are stored in /var/spool/cron .
You can look, but avoid the temptation to edit crontab files here directly and always use crontab -e . If you edit files in /var/spool/cron directly you will lose the benefit of syntax checking that the crontab editor provides, and your changes will not be detected without sending a reload signal to the cron daemon.
Where is the user crontab stored?
Since upgrading my user’s crontab has been wiped out. This is not the first time this has happened this year and it’s a pain restoring it each time. I’d like to be able to back up the crontab for my user but for that I need to know where it’s stored.
@WalterTross Yeah it’s quite annoying. I would guess it’s a side-effect of updating the cron package but I agree — it’s not something that should happen.
Just want to mention that there are instructions here about how to reconstruct an accidentally deleted crontab using logs: superuser.com/questions/384109/crontab-deleted It’s not really what you were asking but it might be of use to someone.
4 Answers 4
Actually, it’s not recommended to handle those files by hand. Per crontab man page:
Each user can have their own crontab, and though
these are files in /var/spool/cron/crontabs , they are not
intended to be edited directly.
Files under /var/spool are considered temporary/working, that’s why they probably get deleted during an upgrade, though a closer look at the cron package’s upgrade scripts may shed some light on this.
Anyway, it’s always a good practice to back up your cron entries or keep them in a file in your home directory.
I assume you’re using crontab -e to create crontab files on the fly. If so, you can get a «copy» of your crontab file by doing crontab -l . Pipe that to a file to get a «backup»:
Then you can edit that my-crontab file to add or modify entries, and then «install» it by giving it to crontab:
This does the same syntax checking as crontab -e .