Should I edit /etc/crontab or run crontab -e as root?

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?


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.


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.