On Mon, Jan 22, 2024 at 2:00 PM Shawn Heisey <apa...@elyograg.org.invalid> wrote:
> 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. > > EFS is NFS. If you mount it as v4 you should get good support for things like locking but if there are options you should try them out.
