[Koha-bugs] [Bug 11078] rebuild_zebra.pl can lose updates due to race condition during full rebuilds

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11078

--- Comment #13 from Doug Kingston <dpk at randomnotes.org> ---
(In reply to Robin Sheat from comment #12)
> (In reply to Doug Kingston from comment #10)
> > The existing koha scripts that create koha instances call
> >   install -d -o $kohauser -g $kohauser /var/lock/koha/$kohasite
> > When invoked this way, only the last directory in this path is owned
> > by the user and the intervening directories are owned by root. 
> > rebuild_zebra.pl
> > is run as $kohauser so it cannot create another directory under
> > /var/lock/koha.
> 
> Yeah, I just checked and found that. In that case, it might be best to use
> that pattern? If it's only applicable to a package installation, it is
> something we could put in just for that case without too much difficulty.
I don't think we can use that pattern because it relies on running as root.  I
think the best solution here is to have each instance create its own directory
under /var/lock which is guaranteed to be in mode 1777 (with the t bit set).
Since /var/lock is often on tmpfs its gone after a reboot and we can't rely in
a subdirectory maintained.  I think this is now in the safest, most maintable
state.

> 
> > My changes make sure this is set for proper installs (see the change to
> > rewrite-config.pl, but I am happy to put in a fallback if QA team wants it.
> > This level of protection is not present for other config variables.
> > Lots of other things will go pear-shaped if their definition is missing.
> 
> Your changes only apply to _new_ installs. Anyone with a pre-existing
> installation who doesn't update their koha-conf.xml will have problems. This
> will be most people.
Fair enough, I'll update it to use /var/lock if the lockdir variable is not
defined.

> 
> > Thanks for the pointer, I did not know about that template.  This is just
> > what code reviews are for.
> 
> No problem :)

-- 
You are receiving this mail because:
You are watching all bug changes.