--- Bill Moseley <email@example.com> wrote:
> The locking is overkill, as why would you run the script more than
Say you have it in a crontab and, for whatever reason, the cronjob is
still running when it comes around again...or say you decide to rebuild
the index (with the build script of course!) and the cronjob you forgot
about starts up?
> (BTW - is there a way to create a lock in a shell script that isn't a
> race condition? Maybe one could run a perl command to use sysopen
> with O_CREAT and look at the exit status.)
I don't know of a way to flock() from a shell script, but it might
exist. My method is not 100% bullet proof, but as you asked: why would
you start two swish builds at the exact same time?
Perl would be another way of going. I thought about it, but I already
had the skeleton of this script from a few other of my daily cron
scripts I've written.
> What features do you lose if you just do this in a
> 0 2 * * * swish-e -c /path/to/config -v0
1. "Lock" to make sure other build is not under way
2. If a build fails, won't try to rebuild until first problems are
3. Different email address lists for "success" and "error" exits.
Of course, all of these are configurable (can be disabled).
> Seems like that's less error prone than a 348 line script.
On a single-user system (or a single-admin system), probably.
But for a turnkey system or a system with Senior and Junior admins
banging away at things, telling everyone to run swish by *one*
mechanism that does locking and reporting is a Good Thing. This is how
I gatekeep a bunch of different apps (don't let them know the real
command-name, just tell them about the gatekeeper script).
> Swish should only do the mv if the index is written correctly so it's
> not a problem to index a live site. It's not atomic like the
> directory move (because it's moving two files)
The directory move stuff is used in other gatekeeper scripts I have. I
figured I'd put it in. And heck, if swish-e decides to start using
more files, the feature is already there!
> Daily emails saying the site was indexed successfully seem pointless
> and can make you miss when a problem really does happen.
Agreed, and that's why I make it quite configurable. It might be that
someone wants to have an "audit" email address for tracking the results
of all builds (every worked on the website of a large corporation? You
want to talk about paranoid!)
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
Received on Fri Nov 8 20:06:02 2002