Date: Fri, 28 Jun 1996 08:43:27 -0700 From: "M.R.Murphy" <mrm@MARMOT.Mole.ORG> To: mrm@mole.Mole.ORG, rjk@sparcmill.grauel.com Cc: freebsd-questions@freebsd.org, jkh@time.cdrom.com Subject: Re: The crontab controversy Message-ID: <199606281543.IAA23933@meerkat.mole.org>
next in thread | raw e-mail | index | archive | help
Richard J Kuhns writes: > > I'll try not to run this too far into the ground... Me too, but it may be close. > > 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. Not quite. the /var/cron/tab files provide individual environments, not a common environment. Sure they can be individually modified with crontab to make them the same, but it is more work than a single _system_ cron table (/etc/crontab) that provides for execution of periodic tasks under multiple userids. Yes, one can also do this from /var/cron/tab/root, but less conveniently. I like convenient. I'm lazy. > > > 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? User "blort" can be denied in /var/spool/cron/tabs/* and /etc/crontab can still have periodic tasks executed under user "blort". > > > > > 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. It is straightforward, but you have to do each user separately. As in news, uucp, www, root, ... That's more work than just one system file to edit with vi. See the part above where I'm lazy. > > > 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. The hitch in your argument is that the only difference in format between /etc/crontab and /var/spool/cron/tabs/* is that the USER must be specified in /etc/crontab. It has to be specified so it can work with multiple users. It's in the documentation, though it could be better stated and more clear. > > > 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 ;-). I think this is just a documentation problem. What Annalise says, put a comment in /etc/crontab saying how it differs from /var/spool/cron/tabs/* and say that it's a _system_ crontab and not _root's_ crontab, ought to make it understandable. WRT Congress, be thankful we don't get the government we pay for :-) Hey, Jordan, would you ask someone to re-comment /etc/crontab? -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606281543.IAA23933>