53

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?

Improve this question
2
  • 9
    For me, this looks like a legitimate best-practice question, and I hope it doesn't get closed. I can already see relevant, factual points being made in the answers, and comments thereto.
    – MadHatter
    Sep 6, 2016 at 8:04
  • 1
    I once went to type crontab -l (to list the crontab) but I typed crontab -; by mistake which deleted my crontab instead. I learned a lot that day.
    – Lumberjack
    Sep 7, 2016 at 15:08

4 Answers 4

Reset to default
68

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.

Improve this answer
3
  • 19
    A drawback of editing /etc/crontab is that a merge will be required whenever you update the cron package. You don't have that problem if you just add a new file to one of the /etc/cron.* directories.
    – kasperd
    Sep 6, 2016 at 8:00
  • 2
    You should add that in most distros /etc/cron.[hourly |daily |weekly |monthly] holds executables while /etc/cron.d holds crontabs. Other than that, +1.
    – GnP
    Sep 12, 2016 at 17:56
  • 1
    I'm definitely a fan of the cron.[timing] directories, I rarely need anything more granular than the commn options. Though please note that some distros, particularly Ubuntu, will silently ignore scripts with file extensions in these folders (a fairly internet-outraging bug, considering most people would add .sh, that may have been fixed in recent distros). Very difficult to work out why scripts weren't working in that situation - at least adding to the crontab is guaranteed to execute.
    – Gargravarr
    Sep 13, 2016 at 10:40
15

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.

Improve this answer
5
  • 2
    +1 Good point about the syntax validation, although it recognises some syntax errors it is also far from fool-proof (i.e. it will happily allow you to enter a /etc/crontab line with a username in the 6th column). - Although I would like to argue that using interactive tools is not "best practice", you ought to automate with tools like Puppet/Salt/Ansible etc. and should not be configuring servers by hand anymore in the first place. On the other hand if you are old-school, then indeed do use your tools.
    – HBruijn
    Sep 6, 2016 at 19:42
  • Ansible and others are good if you configure 5+ servers, but not worth the hassle for just 1. You could argue that with just 1 server an Ansible script gives you the ability to rebuild it identically when it fails 2 years down the line, but at that point the script is likely to not work anymore due to distros/repos changes.
    – marcv81
    Sep 7, 2016 at 2:38
  • This is the reason I vehemently disagree with the accepted answer. Whatever changes are being made should be run through this validation process at least once. If one then copies a line from the new crontab and provides it to an automated tool to propagate to other servers, then it's the best of both worlds.
    – Monty Harder
    Sep 7, 2016 at 15:29
  • Neither help if launching a script, and there are errors in the script, so dry run testing is required either way.
    – mckenzm
    Sep 8, 2016 at 3:40
  • @mckenzm agreed, but there's only so much idiot-proofing you can apply :)
    – Gargravarr
    Sep 8, 2016 at 13:30
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.

Improve this answer
2
  • 3
    -1 The big disadvantage of doing the above is that the user is now able to modify/delete/break the cronjob as well, which is typically not desirable when you as the admin spent your valuable time setting things up... Also when the user is a service account and that account is locked/expired the service will continue to run but personal cron tabs for locked accounts usually will get disabled.
    – HBruijn
    Sep 6, 2016 at 19:35
  • If the user specified here is a public user such as member of a public terminal service environment, you are right. However, if the matter is about a service/agent's user... on second thought, it is really about style.
    – Aesnak
    Sep 7, 2016 at 7:51
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.

Improve this answer
0

You must log in to answer this question.

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