[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 #16 from Doug Kingston <dpk at randomnotes.org> ---
(In reply to Robin Sheat from comment #15)
> (In reply to Doug Kingston from comment #13)
> > I don't think we can use that pattern because it relies on running as root. 
> 
> Well, I'm trying to figure a way that'll work with the scheme that the
> packages currently use. For them we can expect /var/lock/koha/instancename
> to exist and have the correct user permissions, as it's already used for
> locking zebrasrv. So we could have a rebuild-zebra.lck (or whatever) lock
> file under there.
My code works with the system as implemented (packages or no packages).
There is not a easy way to get the instance name (unless I am mistaken) right
now without introducing yet more variables and possible problems.  Is there a
pressing reason for the lock file to live under /var/lock/koha/instancename
that warrants the additional complexity?  And whatever we come up with needs
to work for new and legacy installs.  Ideas that keep get us closer without
undue complexity are welcome.  Otherwise, lets get this in and iterate.

> 
> > 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.
> 
> We can rely on it for packages as it's created at boot, if needed (and is
> already being used.)
> 
> > Fair enough, I'll update it to use /var/lock if the lockdir variable is not
> > defined.
> 
> Cool.

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