119

I am trying to automate the refreshing of awstats for my webserver and understand that I need to use cron to set that up. So each user has a crontab file?

I was following the instructions here community/AWStats

And it says to go to the file at: /etc/crontab

That file already has some information in it. Is this the main crontab file or something? I have seen some instructions online to use the file that pops up with crontab -e.

What is the proper file to use and the best way to do this?

If I schedule a task as my non-root user, will it run by itself at the time interval as specified, with no issues?

Will I need to restart the server after saving the cron job in the crontab file before it will start working?

2 Answers 2

124

What is the proper file to use and best way to do this?

crontab -e is the best way to do it - this will allow you to easily edit per-user crontabs.

If I schedule a task as my non-root user, will it run by itself at the time interval as specified, with no issues?

Yes, and it will run with the privileges of that user account.

As a principle, it is best to run scheduled tasks with the lowest privileges you can get away with, so if what you are doing will not require root, don't use root. If you don't even need to be able to access your account's files and folders, then you can create a new user and use that user account only for that task. On the other hand if your task does require root, use root's crontab (su / sudo su to root then use crontab -e).

Will I need to restart the server after saving the cron job in the crontab file before it will start working?

No it'll start working straight away (well, the next possible scheduled time).

Why not edit the file directly? Where is it located?

The user crontab files are located in /var/spool/cron/crontabs, but their permissions are set in such a way that they can't be traversed to without superuser permission (but once open and the cron process drops privileges it can still access the file).

The system is not designed for end users to edit these files directly, and indeed the top of the file has a stern DO NOT EDIT THIS FILE warning at the top to this effect. The file is instead designed to be edited via crontab -e which sets up a temporary mirror of the file in /tmp for editing - without the stern warning - after which it checks and installs the permanent crontab file itself. This can all be done without superuser permission.

If you did edit the crontab file directly I don't know what the result would be. It's possible it simply wouldn't take effect until next restart and any errors may be hard to debug.

2
  • 8
    crontab -e lets you edit your user crontab without sudo. The user crontabs are in /var/spool/cron/crontabs which is a directory that cannot be accessed without superuser permission (but in such a way that once cron drops privileges it's still able to read it). Even if you do use sudo to try and edit the file directly, you see a big warning at the top, "DO NOT EDIT THIS FILE" - the file is designed to be edited using the crontab command which uses a temporary copy in /tmp and then installs it after you save. Feb 21, 2018 at 13:01
  • In case anyone was wondering why the above comment repeated information given in the answer: The above comment was to answer someone's question that seems to have since been deleted. I then later added the information from the comment into my answer. Feb 14 at 5:48
57

Every user has it's own crontab.

To see it just type

crontab -l

and, yes you've seen it right, when you want to add a crontab then simply do

crontab -e

for the first time you'll be asked about the editor to use with crontab. As you are a newbie as you say, I'd recommend to use nano, it's the simplest editor to use.

The crontab itself works like this

MIN =  Minute 0-60
HOUR = Hour [24-hour clock] 0-23
MDAY = Day of Month 1-31
MON = Month 1-12 OR jan,feb,mar,apr ...
DOW =  Day of Week 0-6 OR sun,mon,tue,wed,thu,fri,sat
COMMAND = Command to be run Any valid command-line

So e.g. to trigger a job every 15 minutes only on monday, you do it like so

*/15 * * * mon /home/me/yourscript.sh

and YES it's very important that you put your cronjob into the crontab of the user which has enough rights to execute it.

So if your script needs to be root or a special user, make sure to su to that user and add the cronjob there.

Also very important!

cronjob is dumb! Yes I said it. Always make sure to enter the full PATH to the application/command/script you are using, because crontab won't work with .bashrc or similar. You always have to make sure that you tell cron where it can find the files and directories.

To answer the rest of your questions:

Of course it will run on it's own, that's what it's there for. But you need to check that cronjob really does it, or if it's missing something. E.g. log into a logfile to see if it really works.

And NO, a restart is not needed. A restart with linux is normally only needed, if you install a new kernel. For it to use you'd need to reboot. Almost everything else can be done without reboot in Linux. Of course there are exceptions, but in general this statement is correct.

2
  • 1
    to check you time format review this site crontab.guru
    – Astm
    Sep 24, 2019 at 10:25
  • I needed the -u user option as the job I was looking for was running under a different user.
    – ergohack
    Feb 23 at 0:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .