Or only catch the specific exception and only swallow that? But yeah,
this is something that should change as I see this "in the field" and
a more specific error message would short-circuit a lot of unnecessary
pain.
see: LUCENE-7959
Erick
On Wed, Sep 6, 2017 at 5:49 AM, Shawn Heisey wrote:
> O
On 9/4/2017 5:53 PM, Erick Erickson wrote:
> Gah, thanks for letting us know. I can't tell you how often
> permissions issues have tripped me up. You're right, it does seem like
> there could be a better error message though.
I see this code in NativeFSLockFactory, code that completely ignores any
-Original Message-
> From: Erick Erickson [mailto:erickerick...@gmail.com]
> Sent: Saturday, 26 August 2017 9:15 a.m.
> To: solr-user
> Subject: Re: write.lock file appears and solr wont open
>
> Odd. The way core discovery works, it starts at SOLR_HOME and recursively
).
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Saturday, 26 August 2017 9:15 a.m.
To: solr-user
Subject: Re: write.lock file appears and solr wont open
Odd. The way core discovery works, it starts at SOLR_HOME and recursively
descends the directories
Odd. The way core discovery works, it starts at SOLR_HOME and
recursively descends the directories. Whenever the recursion finds a
"core.properties" file it says "Aha, this must be a core". From there
it assumes the data directory is immediately below where it found the
core.properties file in the
SOLR_HOME is /var/www/solr/data
The zip was actually the entire data directory which also included configsets.
And yes core.properties is in var/www/solr/data/prindex (just has single line
name=prindex, in it). No other cores are present.
The data directory should have been unzipped before the so
It's certainly possible to move a core like this. You say you moved
the core. Did you move the core.properties file as well? And did it
point to the _same_ directory as the original (dataDir property)? The
whole purpose of write.lock is to keep two cores from being able to
update the same index at
