On 1/18/24 09:08, uyil...@vivaldi.net.INVALID wrote:
I had a very similar problem when running Solr on EKS kubernetes cluster. The solution I found was
to add a pre_stop shutdown hook to the kubernetes deployment, which runs the command
"/opt/solr/bin/solr stop -k solrrocks -p 8983" to gracefully stop Solr before the pod is
killed. I also added a 180 second grace period via "termination_grace_period_seconds".
The downside is it takes at least 3 minutes to shut down the pod now.
That way lock file gets cleared before Solr is restarted. I don't know if the
same approach can be used in ECS though.
The bin/solr script already has a 180 second grace period on shutdown
before it forcefully terminates the process. It won't wait the full 3
minutes, though ... it will exit quickly if the shutdown happens sooner,
which is usually what happens.
The presence of the lock files themselves shouldn't cause an issue with
the "native" lock type. But if something is running that already has
them locked, then there is an issue.
Going back to the OP, changing the lock type in solrconfig.xml should
not be required unless the filesystem is on the network using something
like NFS or SMB, something that does not have all the same locking
capabilities as a locally mounted filesystem. The default of "native"
tends to be the best option.
Thanks,
Shawn
