|
|
 
On Red Hat/Fedora/CentOS, you can't simply look at that output of crontab -l to see what is scheduled to run as root, even if you are running as root. For instance:
# crontab -l
0 0 * * * /bin/some/command
# cat /var/spool/cron/root
0 0 * * * /bin/some/command
#
|
There can be another system crontab located in /etc/crontab:
# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
25 3 * * * root up2date -u
|
This file is checked *in addition* to the /var/spool/cron directory. Crond also checks /etc/cron.d. Seems kind of messy to us that root doesn't simply store all of this in the location referenced by crontab -l. True, we could change it, but then the updates to the Red Hat jobs we have running woudn't work right. I suppose this is the reason for the more complicated configuration. Notice the nightly up2date task on this box. Be careful about running the daily up2date on some systems. We have seen it lock up some servers and prefer to do it manually. Really, do you want your important systems patching themselves? What if up2date patched the major system libraries, glibc or something? Yow!! Or what if a patch to Apache caused a slightly different interprettation of your httpd.conf file... it could happen. Anyway... beware.
|
|
