For Hibernate Search's index files, we are now using NativeFSLockFactory, presumably because we upgraded Hibernate Search. (NB it may not be the default on all platforms.) NativeFSLockFactory is supposed to delete lock files automatically in case of a crash. We should check whether Hibernate Search is now smart enough to report lock problems at startup all by itself [1], and if so, we can remove the lock check in ZanataInit. We should test with (a) two copies of Zanata running (the second one should refuse to run because the locks are live) and (b) with stale lock files when starting Zanata (in which case Zanata should delete the lock and create a new one). We should also try killing the Zanata process to check that the native locks are really removed by NativeFSLockFactory as promised. On the other hand, if we decide to keep the lock check in ZanataInit, we should at least change the error message it generates: as long as the original Hibernate Search process is dead, it should be safe to delete the lock file but keep the index directories, thus avoiding the need to re-index everything. [1] In the past, there were no error messages from Hibernate Search: the background indexing thread just died or blocked silently, and new objects were not indexed.
ZanataInit no longer prevents the deployment if .lock files are found - in most cases it just outputs an INFO message. See https://github.com/zanata/zanata-server/pull/562. Note: I said in the bug report that "as long as the original Hibernate Search process is dead, it should be safe to delete the lock file but keep the index directories, thus avoiding the need to re-index everything", but I'm not sure if that is true or not. The fact that Hibernate Search now ignores stale locks /suggests/ that it may not be important. We have recently had complaints that Zanata 3.6.2 was not indexing new changes, but this may have been a misunderstanding.