[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Niced cron jobs



On Sat, Jun 26, 1999 at 10:35:44PM -0500, Steve Greenland wrote:
> On 26-Jun-99, 21:37 (CDT), Craig Sanders <cas@taz.net.au> wrote: 
> > agreed. i have no objection at all to making it a configurable option.
> > in fact, i'm in favour of such things - the more we make it easy for
> > users to tweak and fine-tune their machines, the better.
> > 
> > my objection was only against forcing this behaviour on everyone.
> > i don't even care very much what the default is (although i prefer
> > NICENESS=0), as long as it's a conffile that persists across upgrades.
> 
> This is the second time you've used the term "forcing". Nobody (and
> certainly not me) is forcing anybody to do anything. 

setting nice in the system cron jobs without providing a way to either
turn it off or change the nice level *IS* forcing it on everyone.

there is a very simple solution which gives everyone what they want
- make cron's "niceness" a conffile parameter. those who want niced
cron jobs can have them, those who don't want them don't have to have
them...and all without making people have to edit yet another config
file after every upgrade. set it once and forget about it.

this kind of attention to detail is why debian is better than other
distributions...we really do have a system which *CAN* be safely
upgraded in place, without having to remember dozens of little things
that have to be re-hacked every time you upgrade (which would be a real
PITA, especially if you are like me and have dozens of debian systems
and upgrade them every week or two on average)

> /etc/crontab is a conffile. Always has been, always will be[1]. If
> you've got a heavily loaded server, my guess is that you've probably
> also mucked with /etc/crontab, in which case you'll never see the
> change.

no, i've never needed to modify /etc/crontab since the invention of
the /etc/cron.d subdirectory (yet another instance where debian offers
new and useful features without sacrificing flexibility or safety of
upgrades). the default /etc/crontab works fine and gets upgraded every
time it changes in a new cron package.


> <rant> I'm getting extremely annoyed with the many people who want
> configuration files delivered tuned for their specific situation without
> any thought at all about the general consequences. 

and this is _EXACTLY_ why i objected to hard-coding a nice value in
/etc/crontab. it is fine-tuning for a very specific situation that very
few people will notice any benefit from and which will cause harm to
others.

hard-coding stuff is evil.  providing a new configuration option is good.

debian is better because we have several hundred developers, many of
whom are excellent system administrators with many years of experience.
someone suggests something, someone else enhances the suggestions,
another points out potential problems and ways to work around them.

ideas rapidly evolve from something that is useful in one specific
situation to something which is generically useful - the combined
ideas and experiences of us all results in systems that work well for
'default' installs while still providing a great deal of flexibility
for customisation, without having to mutate your system so much that
uprgrading it is dangerous.

i've seen this occur repeatedly on the debian lists over the years.
(sometimes the arguments get heated but we all do have a genuine desire
to come up with the best solution)

> In the meantime, I'm going to play around with the effects of "nice
> -10" on commands that whack the disk (aka "checksecurity") and decide
> for myself if the benefit exists, and exceeds the downside issue that
> Craig has raised.

thank you.

craig

--
craig sanders


Reply to: