cronjob entry in crontab -e vs /etc/crontab . Which one is better?

Question

What is the difference when I put crontab entry in crontab -e (the default location is : /var/spool/cron/username ) and in /etc/crontab? I mean crond daemon will essentially execute both cron jobs. Then why there are two different ways to schedule cronjob ? Which one preferred over the other ?

Puncture

The jobs scheduled to run under /etc/crontab will run as root, the others will not? – Bookworm

what if it is /var/spool/cron/root ? then which one is preferred? – Puncture

There's probably not a "right" answer to this - but I tend to think if it's something specific to the root user's account (e.g. generating some reports that get e-mailed to root, which forwards it to wherever) it should go in /var/spool/cron/crontabs/root, but if it's just a system-wide admin task, like cleaning up /tmp or something, then it belongs in /etc/crontab//etc/cron.d/* (or /etc/cron.{hourly,daily,weekly,monthly} as appropriate). That's just my opinion, though... – Fission

Answer 1

The difference is that the crontab command is the interface provided by the system for users to manipulate their crontabs. The /etc/crontab file is a special case file used to implement a system-wide crontab. /var/spool/cron/crontabs/$USER (or whatever the path happens to be) is an implementation detail.

If you can schedule jobs using the crontab command, you should do so.

Manually editing the contents of /etc/crontab (a) requires root access, and (b) is more error-prone. You can mess up your system that way.

If the jobs are to be run under your own user account, there's no need to use root access.

Even if the jobs are to run as root, it probably still makes more sense to use the crontab command invoked from the root account. (For one thing, it should detect syntax errors in the file.)

Personally, I don't use crontab -e. Instead, I have a crontab file that I keep in a source control system, and I use the crontab filename form of the command to install it. That way, if I mess something up, it's easy to revert to an earlier version.

Savitt

But if using crontab filename to install, and you're sure the code is fine, it doesn't really matter which of those 2 crontabs you are overwriting, as far as I know. – Trusting

@jessuppi It certainly does matter. crontab filename will always update your personal crontab (even if you run it as root), never /etc/crontab. The two crontabs use different syntaxes. /etc/crontab has an extra column specifying the user to run the command. – Savitt

@KeithThompson Those are 2 great points... maybe you can update your answer to remind users of that? In our SlickStack project (FOSS), we use the root user crontab as there seems to be a long-held belief that /etc/crontab is holy and untouchable, and might one day be used by Linux distros for something system-related. Although the root user crontab path is a bit convoluted... – Trusting

@jessuppi: Why do you care about the path of the root user crontab? You should only manipulate it via the crontab command. – Savitt

@KeithThompson I understand and do mate, but messy paths are never fun. – Trusting

@JesseNickles Messy paths are neither fun nor not fun if you ignore them, and you should. I use crontab all the time, and I honestly don't know where the crontab file is stored (though I could find out easily enough). – Savitt

Answer 2

Differences :

$PATH

(On my Red Hat 7 system)

• Running via /etc/crontab : $PATH is /sbin:/bin:/usr/sbin:/usr/bin
• Running via crontab -e : $PATH is /usr/bin:/bin

Access

• Only root can access /etc/crontab
• User can access their own /var/spool/cron/user-name

Format

• /etc/crontab needs an extra parameter, preceding the command, which specifies the user.
• crontab -e (/var/spool/cron/user-name) obviously does not need the user name in the crontab entry.

Patriarchy