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

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Oct 30 04:39:00 CET 2013


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

--- Comment #17 from Robin Sheat <robin at catalyst.net.nz> ---
(In reply to Doug Kingston from comment #16)
> My code works with the system as implemented (packages or no packages).

I know, I'm trying to get it to a point where it also works cleanly with the
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.  

There is for packages, we can put __KOHASITE__ in the koha-conf.xml template.
It's not super tidy, as we'll then be creating an unnecessary directory under
that, but that's not the end of the world by any means.

> Is there
> a pressing reason for the lock file to live under /var/lock/koha/instancename
> that warrants the additional complexity?  

I'm not sure if there are any specific debian policies on what goes in the lock
dir, but as we progress towards making things debian-clean, we ought to avoid
doing things in an obviously inconsistent fashion.

> 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.

I'd say for now to modify the template patch to be:
/var/lock/koha/__KOHASITE__
and it'll be clean enough. Not quite as much as I'd like, but it'll do, and
it's hidden away. And we know this is safe to do as they're configured in the
init.d script.

It'll also work on tar, git, etc. systems as they'll use plain /var/lock.

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


More information about the Koha-bugs mailing list