Erick - thank you, the issue was the second one you mentioned -- I completely forgot about changes that were made in conf files I never copied over (including schema.xml). Once I overwrote and reloaded I had no problems reindexing. I guess I had forgotten to check those since I was copying various files back and forth... the errors in the solr log clearly showed that what was happening.
Best, Amanda ------ Dr. Amanda Shuman Post-doc researcher, University of Freiburg, The Maoist Legacy Project <http://www.maoistlegacy.uni-freiburg.de/> PhD, University of California, Santa Cruz http://www.amandashuman.net/ http://www.prchistoryresources.org/ Office: +49 (0) 761 203 4925 On Thu, Jun 7, 2018 at 5:39 PM, Erick Erickson <erickerick...@gmail.com> wrote: > Amanda: > > Your Solr log will record each update that comes through. It's a > little opaque, by default it'll show you the first 10 IDs of each > batch it receives. > > Guesses: > - you're somehow having the same ID (<uniqueKey>) assigned to multiple > documents > - your schemas are a bit different and the docs can't be indexed > (undefined field for instance). > > > Best, > Erick > > > On Thu, Jun 7, 2018 at 7:49 AM, Amanda Shuman <amanda.shu...@gmail.com> > wrote: > > Thanks, Shawn, that is a remarkably clear description. > > > > I am able to create the core and all appears fine, but when I go to > index I > > am unfortunately running into a new problem. I am indexing from the same > > site content as before (it's just an Omeka install with a solr plug-in > that > > reindexes the sitE), but now it only indexes 3 (!) records out of 3000+ > and > > then stops. I have no idea why. The old core - with a different name - > > still works, even I choose to reindex it. Now I have to figure out which > > error logs to check -- Solr or Omeka. > > > > Amanda > > > > ------ > > Dr. Amanda Shuman > > Post-doc researcher, University of Freiburg, The Maoist Legacy Project > > <http://www.maoistlegacy.uni-freiburg.de/> > > PhD, University of California, Santa Cruz > > http://www.amandashuman.net/ > > http://www.prchistoryresources.org/ > > Office: +49 (0) 761 203 4925 > > > > > > On Thu, Jun 7, 2018 at 3:08 PM, Shawn Heisey <apa...@elyograg.org> > wrote: > > > >> On 6/7/2018 4:12 AM, Amanda Shuman wrote: > >> > >>> Definitely not a permissions problem - everything is run by the solr > user, > >>> which owns everything in the directories. I just can't figure out why > the > >>> default working directory is in opt rather than var (which is where it > >>> should be according to a previous chain I was in). > >>> > >>> But at this point I'm at a total loss, so maybe a fresh install > wouldn't > >>> hurt. > >>> > >> > >> The "bin/solr" script, which is ultimately how Solr is started even when > >> it is installed as a service, initially sets the current working > directory > >> to a directory that it knows as SOLR_TIP. This is the directory > containing > >> bin, server, and others. It defaults to /opt/solr when Solr is > installed > >> as a service. > >> > >> Then just before Solr is started, the script will change the current > >> working directory to the server directory, which is a subdirectory of > >> SOLR_TIP. > >> > >> So when Solr starts, the current working directory is $SOLR_TIP/server. > >> > >> The service installer sets the owner of everything in SOLR_TIP to root. > >> The solr user has absolutely no reason to write to that directory at > all. > >> Everything that Solr writes will be to an absolute path under the "var > dir" > >> given during service install, which defaults to /var/solr. THAT > directory > >> and all its contents will be owned by the user specified during install, > >> which defaults to solr. > >> > >> The current working directory is where the developers want it, and will > >> not be in the "var dir". Its location is critical for correct Jetty > >> operation. When Solr is configured in the expected way for a service > >> install, it does not use the current working directory. > >> > >> Thanks, > >> Shawn > >> > >> >
