[Fwd: Output of fcron job: '/usr/bin/render-blfs-book.sh']

Anderson Lizardo lizardo at linuxfromscratch.org
Mon Aug 23 16:13:50 PDT 2004


On Sunday 22 August 2004 13:15, Gerard Beekmans wrote:
> The race condition would be due to the website update script -- it
> touches upon all of the /home/httpd/www.linuxfromscratch.org directory.
> It runs at 02:00 server time.
>
> How we can prevent this? If you look at the /usr/bin/render-lfs-book.sh
> script you will notice it creates a lockfile to make sure if the script
> is run again by something/somebody it won't try to generate the book
> twice or more times which wastes CPU and will cause their own set of
> race conditions.
>
> We should probably have all of our scripts that somehow update files in
> the website look for the various lock files. In particular, the
> run-update-website.sh script should not run if render-lfs-book,
> blfs-book, *edguide, etc. are running. The website script would go into
> a loop (like the lfs-render script. It'll sleep for 10 minutes and try
> again) until there isn't anything running that would interfere with its
> operation. Likewise, then the website script is running it creates its
> own lockfile (even if it's in a loop waiting for something else) and the
> render-*lfs scripts should not attempt to run if the website area is
> locked.

I've added some code to update-website.sh to look for lock files of other 
scripts that touch /home/httpd/www.linuxfromscratch.org. They are:
render-blfs-{book,edguide}.sh
render-lfs-book.sh

Let me know if some other script is missing.

Regarding the race conditions, they will not be a problem when we implement 
the post-commit hook for www, mainly 
because /home/httpd/www.linuxfromscratch.org will always be there and 
basically it will be a normal svn tree updated with "svn update" (amongst 
other things). This means that the various rendering scripts will be able to 
run concurrently.

I already have a working script that I should put on-line RSN. I've already 
done some tests with it, and it's working fine so far (and is a _lot_ faster 
than the current one because it's acutally a Makefile, updating only the 
files whose dependencies where changed).
-- 
Anderson Lizardo
lizardo at linuxfromscratch.org
http://www.linuxfromscratch.org/



More information about the website mailing list