57

I'm setting up regular system maintenance tasks which have to run as root. I plan to use the flavour of cron which comes with Ubuntu 14.04 LTS as the default.

I see the previous admin (who since left the company) edited /etc/crontab directly. However I understand another possible approach would be to use crontab -e as root. Are there any compelling arguments to use one or the other, or is it down to preference?

HBruijn
  • 84,206
  • 24
  • 145
  • 224
marcv81
  • 682

5 Answers5

71

It might be useful to note that jobs in a personal crontab (crontab -e) are always executed as their owner, where /etc/crontab contains an additional mandatory <user> field allowing an admin to configure the job to run as a non-root user.

Editing the system crontab or setting up a personal crontab for root are probably a bit more portable, not specific to certain Linux distributions and arguably more convenient for a person to maintain, with all jobs in a single file but:

Personally I favour a third option: for each scheduled task drop either

  • a file in /etc/cron.d/ with a cron snippet
  • an executable (script) in the relevant /etc/cron.[hourly |daily |weekly |monthly] directory.

That is easier to script (you can simply create/overwrite/delete such files and you don't have to muck about in the contents of a single crontab file) and that works well with configuration management tooling and that is what package managers are already doing anyway.

Jobs/scripts in /etc/cron.[hourly |daily |weekly |monthly] are always executed as root, where the cron snippets in /etc/cron.d/ allow both setting a custom schedule as well as running as a different user with that same mandatory <user> field found in /etc/crontab.

HBruijn
  • 84,206
  • 24
  • 145
  • 224
18

As best I recall, crontab -e has the added advantage that it verifies the crontab syntax before installing it, and will error and restore the previous if you make a mistake. This way, anything that was previously working won't suddenly stop if you get the syntax wrong. I think best practise is to use the utilities, like running visudo rather than editing /etc/sudoers directly.

3

In order to be sure for adding a cron job which require a specific user 's rights, i personally use the following command :

 # crontab -u <user> -e

You can add sudo too.

As @rackandboneman stated, there is no need to mess with /etc/cron.d/ files. If the matter is about user 's cron jobs, use the features of crontabcommand.

Aesnak
  • 571
2

It is really a style question, there is a reason multiple methods are offered by the OS. Just be consistent and do not mix and match if you do not want to confuse anyone else (or yourself after some time of not dealing with the system) - if it is hard to see what tasks are actually scheduled across the whole host, it tends to end in nasty surprises.

1

Note that some distros like Amazon Linux may not have crontab -e available: See https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2023.html#deprecated-cron

So in this case you could use a method above to edit crontab in a different way (sudo vim /etc/crontab for example), or install the cronie package, or use systemd as recommended by the docs ( however I find crontab more familiar and I'm editing /etc/crontab by hand on Amazon Linux 2023).

Danny
  • 243