Date: Fri, 28 Jun 1996 08:49:50 -0500 From: rjk@sparcmill.grauel.com (Richard J Kuhns) To: "M.R.Murphy" <mrm@MARMOT.Mole.ORG> Cc: freebsd-questions@freebsd.org Subject: Re: The crontab controversy Message-ID: <199606281349.IAA27683@sparcmill.grauel.com> In-Reply-To: <199606271712.KAA20736@meerkat.mole.org> References: <199606271712.KAA20736@meerkat.mole.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'll try not to run this too far into the ground... M. R. Murphy writes: > I suspect that most of the problems folks have with cron are caused by > "I know how it works from past experience. I don't need to read the man > pages for the FreeBSD stuff to see if there are differences. vi works, > what more do I need?" The behavior of cron is documented; people have problems > because they fail to RTFM. Not just with cron, BTW. So, that said, here are > some reasons: > > 1. /etc/crontab can provide a common environment, including a common > MAILTO in an easy to administer manner, > So can the /var/cron/tab files. > 2. /etc/crontab provides for an override of the allow/deny facility > associated with /var/spool/cron/tabs/* in an easy to administer manner, I'm afraid I don't understand this. The allow/deny facility lets you specify who CAN use cron, who CAN'T use cron, or (via empty cron.allow/cron.deny files) specify that everyone/noone can. What's to be overriden? > > 3. /etc/crontab provides for easy administration of multiple user cron > activity for a system maintainer. ``crontab -u user -e'' seems fairly straight-forward to me. > 4. /var/spool/cron/tabs/* provides, when used with an effective allow/deny > policy, a facility that allows users to maintain their own cron activities > without requiring intervention by the system administrator, saving > effort. This, I agree with :-). > 5. The dual crontab scheme provides flexibility. Some like it one way, some > like it another. Those who don't like /etc/crontab can remove it. Those > who don't like /var/spool/cron/tabs don't need to use it and can make > /usr/bin/crontab not executable. Don't just delete /var/spool/cron/tabs > though. That makes cron get noisy in the log. I'm not going to argue about this, either. > 6. Together with an effective group membership policy, the manipulation of > both /etc/crontab and /var/spool/cron/tabs/* can provide a powerful tool > for the scheduling of periodic tasks. (That last one is the kind that > goes behind a bullet on a slide shown by some marketeer :-) I'm not asking that the ability to handle /etc/crontabs be removed, but... > I would grant that some of us might still see NO reason for using 2 different > formats by default, but some of us do, and those who don't like /etc/crontab > can, as I mentioned above, delete it if they so choose. Agreed, but if we used only one format by default, it would be easier for new users and an experienced user would only have to make a simple one-time mod to /var/cron/tab/root to make it work in /etc. > Change for the sake of change is ill-advised. But a change which makes the system easier to understand and more consistent is progress (you know, the opposite of Congress ;-). -- Rich Kuhns rjk@grauel.com PO Box 6249 Tel: (317)477-6000 x319 100 Sawmill Road Lafayette, IN 47903
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606281349.IAA27683>