Solr: 404 error with getting admin page - solr

I've installed Solr on my Ubuntu to this path
/opt/solr/solr-4.10.2
After installing I started Solr:
sudo bin/solr start from /opt/solr/solr-4.10.2 directory
As I can understand it started successfully
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=8385). Happy searching!
But when I try to get to admin page
http://localhost:8983/solr
I got 404 error:
HTTP ERROR: 404
Problem accessing /solr. Reason:
Not Found
Powered by Jetty://
Do you have any suggestion what's going wrong and where to look in order to fix this problem?

Since this error can be caused by a lot of things, you need to access the log file and debug the execution.
First of all, open your Node log file, located in /opt/solr/solr-4.10.2/node1/log and look for something weird (Shift+F for Errors).
Generally, this error occurs when you have a mismatch between the Solr required Java JDK and your current Java JDK.
When I had this problem, I found in the log file the following error message java.lang.UnsupportedClassVersionError: org/apache/solr/servlet/SolrDispatchFilter : Unsupported major.minor version 51.0 and realized the problem was the java version.
To solve this, try to change the current JDK, using the command sudo update-alternatives --config javac.
If the error still occurs, try to uninstall all unused JDK's, because Solr is getting the wrong path.
The final solution to this issue is to open the file /opt/solr/solr-4.10.2/solar.in.sh and edit the SOLR_JAVA_HOME, writing the right JDK path (e.g /usr/lib/jvm/java-1.7.0)
Disclosure: the secret is look in the log file and figure out what is causing the issue.
Cheers.

try:
http://localhost:8983/solr/index.html
[solr's web.xml]
<servlet>
<servlet-name>LoadAdminUI</servlet-name>
<servlet-class>org.apache.solr.servlet.LoadAdminUiServlet</servlet-class>

Related

Starting jetty fail in ubuntu 14

I install the solr-jetty package in a Ubuntu 14 container running in a cloud9 workspace.
To install the package I run the following command:
sudo apt-get install solr-jetty
The installation doesn't return any error.
Then I try to start solr with the following command:
sudo service jetty start
But I receive the following error:
* Starting Jetty servlet engine. jetty
* Jetty servlet engine started, reachable on http://host-solr-3694477:8983/. jetty
...fail!
In the log file of jetty I get the following message:
failed setting default capabilities.
set_caps(CAPS) failed for user 'jetty'
Service exit with a return value of 4
How can I resolve this issue?
To resolve the problem I had to change the user that run jetty from jetty to root.
This can be configured by editing the /etc/default/jetty file.
I think it is not the more correct solution because it can add security problems. If anyone have a better solution ...
Docker user here, same problem, but - this worked for me (and this is as unadvised as changing the user to 'root', suggested above):
https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities
Set the following on your 'docker run' command when creating a container:
--privileged=true
I'm just using docker for development, so not overly concerned yet with the security implications of this.

RVM - Ruby integration was extracted to a separate gem (`remove $LOAD_PATH.unshift`)

I was upgrading to Rails 3.2.6 (ruby 1.9.3-p194) and installing RVM on Debian and using Apache2 server (2.2.19).
I used these very nice instructions: http://dalibornasevic.com/posts/21-rvm-and-passenger-setup-for-rails-2-and-rails-3-apps/
The Apache server configuration /etc/apache2/apache2.conf includes:
LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p194#rails326/gems/passenger-3.0.13/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p194#rails326/gems/passenger-3.0.13
PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p194#rails326/ruby
When I have set everything up (and got rid of tons of errormessages :) the following error message from passenger appears:
RVM - Ruby integration was extracted to a separate gem, it should be installed by default with RVM, remove the $LOAD_PATH.unshift line and all should be fine again.
By commenting out $LOAD_PATH.unshift in MyApp/config/setup_load_paths.rb this error goes away and instead I get a 500 error, Internal Server Error.
/etc/log/apache2/error.log:
[ pid=5262 thr=3075372800 file=ext/apache2/Hooks.cpp:862 time=2012-07-10 12:33:41.475 ]: Unexpected error in mod_passenger: Cannot spawn application '/var/www/MyApp': The spawn server has exited unexpectedly.
Backtrace:
in 'virtual Passenger::SessionPtr Passenger::ApplicationPool::Client::get(const Passenger::PoolOptions&)' (Client.h:742)
in 'Passenger::SessionPtr Hooks::getSession(const Passenger::PoolOptions&)' (Hooks.cpp:294)
in 'int Hooks::handleRequest(request_rec*)' (Hooks.cpp:563)
I would be very pleased if anyone could give me a clue on this problem.
Thank you very much.
Íris

NoClassDefFoundError MimeTypeException with PDF extraction

I am getting an exception trying to use update/extract with PDF files
My Set up is:-
Ubuntu Server 11.10
Tomcat 6
Solr 3.5.0.2011.11.22.15.54.38
I can browse to solr/admin OK
I have put all the contrib/extract and apache-solr-cell3.5.0.jar libraries into the tomcat folder webapps/solr/WEB-INF/lib
I am calling extract using:-
curl "http://localhost:8080/solr/update/extract?uprefix=attr_&fmap.content=attr_content&commit=true" -F "file=/path/to/my.pdf"
error is
java.lang.NoClassDefFoundError: org/apache/tika/mime/MimeTypeException
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:383)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:425)
at org.apache.solr.core.SolrCore.createRequestHandler(SolrCore.java:461)
at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.getWrappedHandler(RequestHandlers.java:248)
at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:239)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
Would appreciate any pointers - the only time this error seems to come up elsewhere is with Nutch and cached results.
I have tried sending the mimetype in the querystring and also a *.doc file but got the same error.
According to the error message it is not a MimeTypeException exception you get: The problem is a NoClassDefFoundError, because Solr cannot load the class MimeTypeException.
Normally this class is present in tika-core.jar.
Make sure you actually have that file and also check if you have a lib statement in your solrconfig.xml pointing to the right directory.
This was due to the basic error of copying the necessary tika libraries (to tomcat6/webapps/solr/WEB-INF/lib) but leaving ownership of the jar files as ROOT instead of chown-ing them to TOMCAT6. After setting the right permission and restarting Tomcat it started working OK
Found the solution of this problem, I was using SolrJ to update my pdf indexing.
after deploy solr to tomcat, I didn't include the following libraries into the tomcat/webapp
and I get all the lazy loading problem, etc etc
I even try to get apache tika...
until I do this...
shutdown tomcat
\apache-solr-3.5.0\contrib\extraction
copy the libraries above to below
\apache-tomcat-7.0.26\webapps\solr\WEB-INF\lib
startup tomcat
cheers

Solr + Jetty Gives HTTP 503 on Debian

(This is a cross-post from servefault. I'm posting it here because no one answered my post there, and I feel that this sort of hits an awkward space half-way between both stackoverflow and serverfault.)
I have modified the example project included with Solr for my needs (removing things like the example stopwords and defining my own schema). Running this project on my mac, everything works fine: I can start Jetty and run search queries. But when I push the project out to a Debian system, I get this error when I try to do search queries:
HTTP ERROR: 503
SERVICE_UNAVAILABLE RequestURI=/solr
Powered by jetty://
The request log shows that a request was made:
10.10.124.14 - - [22/06/2010:22:34:52 +0000] "GET /solr
HTTP/1.1" 503 1311
No error log is produced (at least not on in the ./logs directory).
I have tried to run this project both on openjdk and the Sun JRE. Both started jetty fine, but produced the same error when searching. I am running Debian 9.0.4.
The issue is probably that the datastore in Debian is /var/lib/solr/data and you need to set that line in your version solrconfig.xml instead of the default which is in the base directory /usr/share/solr/ which could be a read only file system.
I've packaged the last solr version in Debian Testing. It seems, that there is some error in the solr configuration so that jetty starts, but it can't start the solr servlet. You must look in the jetty error log to find the reason.
There's lack of manpower in Java Packaging for Debian, so it may well be that there is an error in the solr-jetty package.
The solr-jetty package in Debian stable doesn't work as I recall. Please try from Debian testing!
If you indeed find an error, please don't use random forums but post a bug on bugs.debian.org!
Success!

Building Solr indexes through Haystack throws unknown field error

I'm trying to integrate Haystack with Solr. When I try to build the index, I get an error
"Unknown field django_id" from SOLR. What's causing this to happen?
You also get this error if you haven't given Solr the schema.xml file which Haystack generates for you, as explained here in the docs.
django-haystack.readthedocs.io/en/latest/tutorial.html#reindex
The schema.xml was malformed as I had copied additional text from the console.
If you added new fields to your database and copied the generated XML files from Haystack, you might also be getting this error because you haven't restarted jetty/Tomcat/whatever server you are using. This solved it for me on Ubuntu and Jetty:
sudo /etc/init.d/jetty stop
sudo /etc/init.d/jetty start
(by the way, that would also be the same as simply doing this):
sudo service jetty restart
Or, if you are using tomcat, that would be
sudo service tomcat6 restart
Edit: (tested this with Tomcat, and it solved the same problem again, the same as with Jetty).

Resources