Re: V4 [Partial withdrawal of PROPOSAL] Change Chapter 17 (cron)
Date: Wed, 24 Jan 2001 17:55:13 +0100
From: Johannes Poehlmann <johannes@caldera.de>
Sorry for not getting back to you sooner; I've been way behind on my
e-mail lately....
1. We want to uphold one part of the proposal, which was already
sent out separately:
Date: Thu, 7 Dec 2000 16:02:25 +0100
From: Johannes Poehlmann <johannes@caldera.de>
To: lsb-spec@lists.linuxbase.org
Subject: [PROPOSAL] Get rid of the cron.hourly dir
Message-ID: <20001207160225.A11177@caldera.de>
Our reasons are:
o because many parallel cron scripts cause a big computational load,
it should be possible to serialize these scripts.
This would be risky when using cron.hourly:
What if the serialized scripts need more time then one hour ?
Actually, the easy way to solve the computational load problem is to
observe that cron.hourly merely states that the scripts need to be run
about every 60 minutes; that the only guarantee which is made. But they
don't have to be all run at the same time; so instead of making them be
serialized, a cron program could simply make one run at 7 minutes after
the hour, and another run at 14 minutes after the hour, etc., and they
would be compliant. (And separating the start of each cron.daily entry
by 30 minutes would probably be a good idea too... this would be a very
easy option to add to the run-parts program.)
o we want to allow cron to optimize away hourly disk accesses,
as vixie-cron with a patch from debian already does.
I've in the past showned that it's possible to code cron such that it
doesn't require hourly disk accesses. (i.e., hold open a file
descriptor for the /etc/cron.hourly directory; then every hour or so, do
a fstat to check the modtime; this won't cause a disk access.)
Yes, it requires making a code change. On the other hand, enough other
changes need to be made to a Debian system (and I suspect most systems)
before they will be laptop battery friendly anyway, so this argument
doesn't seem to carry much weight, since at the moment, getting rid of
cron.hourly won't help you much anyway. I'm running Debian/Woody on my
laptop now, and....
* There's a crontab entry for exim which fires every 30 minutes,
regardless of whether you have networking up (dumb, dumb,
dumb, dumb). This causes the atime for the exim inode to be
modified, but worse yet, the fact that the crontab entry
specifies that the entry should run under the mail user, that
means that there are multiple syslog messages from the pam
message hitting /var/log/messages.
The fundamental issue is that running the exim -q needs to run
out of a special long-term running process, ala sendmail -bd,
if you want to avoid waking the disk every time you want to
try to flush the queue; merely running a non-root job out of
crontab guarantees disk activity (because of the syslog
writes), even if the program doesn't do anything else.
* The syslogd is configured to create syslogd mark messages
every 30 minutes (which of course is not synchronized with the
above 30 minute exim queue flush), which in combination to the
above causes the disks to spin up at least four times an hour.
There may have been other laptop unfriendly daemons that were causing my
disk to wake up, but at this point I gave up looking. Suffice it to say
that there were a lot of problems....
o implementing anacron-like functionality produces unnecessary
overhead if cron.hourly is in place (or the anacron-like
functionality had to be switched off for cron.hourly resulting
in inconsistent behaviour).
What sort of "unnecessary" overhead are you referring to? Is this the
need to spin up the disk to write anacron control entry file (i.e.,
/var/spool/anacron/cron.hourly)?
Note though that anacron doesn't support any granularity finer than one
day anyway, and so if a program were to put an entry into /etc/cron.d,
they wouldn't have anacron functionality anyway --- and even if you put
an entry into /etc/anacrontab (and the LSB doesn't guarantee the
presence of anacron), you can't get one hour resolution anyway. So not
having anacron functionality for cron.hourly doesn't seem like either a
huge inconsisntency, given that there's absolutely no way to provide
that sort of functionality anyway.....
If people really don't want cron.hourly, we can remove it at least for
LSB 1.0. But I would like to hear some other opinions about whether or
not we should keep cron.hourly. What do folks think?
- Ted
Reply to: