(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
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11078 --- Comment #16 from Doug Kingston <dpk@randomnotes.org> --- (In reply to Robin Sheat from comment #15) 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.