Re: [PROPOSAL] Get rid of the cron.daily dir

["Theodore Y. Ts'o" <tytso@MIT.EDU>]

   Date: Thu, 7 Dec 2000 16:02:25 +0100
   From: Johannes Poehlmann <johannes@caldera.de>

   Also this proposal would resolve the contradiction in the
   wording of the spec 
   ("more often then dayly", see 

it's easy enough to correct this contradiction by changing daily to
hourly in the above-mentioned text.

   There are technical advantages of "cron snippets" over the
   /etc.cron.daily directory: It is possible not to wake up
   laptop hard disks every hour.

   The debian patch which implements the "cron snippet" directory tries
   to minimize unneded disk access in a way that is not availible for the
   */Hourly directory: If possible, it does not reread the "cron snippets"
   directory. 

   As it is possible (and we even do that) to put a link into the */Hourly
   directory, cron has to check every time if the target of the link has
   changed.

[ Resent from personal mail which I sent to Johannes ]

Wait a second.  I must be missing something, or something isn't making
any sense.

If the target of the link has changed, then the containing directory of
necessity has to have changed.  That's because the symlink system call
doesn't let you replace an existing symlink; you have to delete the old
symlink and create it with a new name.

And in the case of a hard link, you don't care what the target is; you
just want to execute it.

The only case I can imagine where there might be a problem is if you're
trying to optimize the case where the symlink is in the Hourly
directory, and it points to a non-existent target.  If you try to
optimize spinning up the disk in that case, then yes, if the target
is installed again, then you won't notice it.  But trying to execute a
non-existent target won't spin up the disk assuming everything is in
cache, which is likely on a quiescent system.

But the easist way to solve this problem is to simply keep in cache a
memory of everything that's in the Hourly directory, and stat the Hourly
directory once an hour to see if they have changed.  Then try to execute
all of the entries in the (cached) copy of the Hourly directory.  If it
points to a non-existent target, you'll get a failure.  Oh, well, all
cron has to do is ignore the error casued by the non-existent
script/executable.  If it does point to a real script/executable, or is
a real script/executable, then the disk will get spun up anyway, because
of the need to update the atime on the script/executable.  (Unless
you're mounted noatime, in which case all of these problems go away
anyway.)

I haven't tried to code this, so maybe I'm missing something, but I
don't see why this is an issue.  It should be very easy for cron to be
able to use /etc/cron.hourly and not have to worry about waking up a
laptop disk every hour.

                                                - Ted