61

If I put a script in /etc/cron.daily on CentOS what user will it run as? Do they all run as root or as the owner?

Kyle MacFarlane
  • 807
  • 2
  • 9
  • 12

2 Answers2

62

They all run as root. If you need otherwise, use su in the script or add a crontab entry to the user's crontab (man crontab) or the system-wide crontab (whose location I couldn't tell you on CentOS).

geekosaur
  • 7,175
  • 1
  • 20
  • 19
17

Edit: my answer doesn't actually apply in this case, see Zoredache's comment below. Sorry, all (esp. geekosaur). Kyle, note that if you want to run a script regularly as a non-root user, the following may be helpful; just do it through cron.d rather than cron.{hourly,daily,weekly,monthly}.

I hate to contradict, but I fear that geekosaur isn't quite right. They run as root except where specified otherwise. Here's part of my CentOS box's /etc/cron.d/munin file:

# cron-jobs for munin
MAILTO=root
1-56/5 * * * *     munin /usr/share/munin/munin-limits --force

Note how, on the substantive line (line 3), there's a username specified before the executable. This particular cron entry runs as user munin, so provided your cron is similar to CentOS 5's (vixie-cron-4.1-77), you should be able to do likewise.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • 3
    He seems to be talking specifically about cron.daily and cron.weekly, and not things in cron.d/*. – Zoredache Mar 14 '11 at 07:14
  • 4
    D'oh! Thanks, Zoredache; I should read the question more carefully. No coffee yet! I'd delete it, but I think there's still useful information in my answer - just not for the OP - so I'm sort of inclined to let it stand. What do you think? (Sorry for wrongly jumping in, geekosaur). – MadHatter Mar 14 '11 at 07:26
  • geekosaur answered my basic question but I've never known what the cron.d folder is actually for. cron.daily, etc are rather obvious, as is crontab. But where does cron.d sit within it all? – Kyle MacFarlane Mar 14 '11 at 07:27
  • 1
    You've already grasped that the idea of using directories rather than individual files for storing collections is that it makes it easier for a package to add an entry: just drop a file into a dir, instead of trying some complex sed invocation to edit chunks of text in and out of files... – MadHatter Mar 14 '11 at 07:34
  • ... In the case of munin, it needs to run a job every five minutes, and not as root. That's a perfect example of why cron.{hourly,etc.} isn't suitable for everyone; some cron jobs still want to be able to specify a frequency, and maybe a user, and for them, cron.d is better. Others don't, and for them, cron.{hourly,etc.} is simpler, as they just dump a script instead of a script plus a timing/user-setting wrapper. – MadHatter Mar 14 '11 at 07:35