span.fullpost {display:inline;}

Sunday, July 20, 2008

Crontab Locations on Red Hat, Fedora, and CentOS

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.

0 comments:

Tutorialsland By - Templates4all | Free Blogger and web Templates
Free Website templatesFree Flash TemplatesFree joomla templatesSEO Web Design AgencyMusic Videos OnlineFree Wordpress Themes Templatesfreethemes4all.comFree Blog TemplatesLast NewsFree CMS TemplatesFree CSS TemplatesSoccer Videos OnlineFree Wordpress ThemesFree Web Templates