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.
