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

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.,

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: