Hi Shawn!
Thanks for that suggestion, but I had found that file and I had changed it to
80, but still no luck. Solr isn't running because it never started in the first
place. I also tried the -p 80 flag using the install script and it failed.
Tried: ./install_solr_service.sh solr-6.0.0.tgz –p 80
Result: ERROR: Unrecognized or misplaced argument -p!
Tried: ./install_solr_service.sh solr-6.0.0.tgz -i /opt -d /var/solr -u solr -s
solr -p 80
Result:
id: solr: no such user
Creating new user: solr
Adding system user 'solr' (UID 116) ...
Adding new group 'solr' (GID 125) ...
Adding new user 'solr' (UID 116) with group 'solr' ...
Creating home directory '/var/solr' ...
Extracting solr-6.0.0.tgz to /opt
Installing symlink /opt/solr -> /opt/solr-6.0.0 ...
Installing /etc/init.d/solr script ...
Installing /etc/default/solr.in.sh ...
Adding system startup for /etc/init.d/solr ...
/etc/rc0.d/K20solr -> ../init.d/solr
/etc/rc1.d/K20solr -> ../init.d/solr
/etc/rc6.d/K20solr -> ../init.d/solr
/etc/rc2.d/K20solr -> ../init.d/solr
/etc/rc3.d/K20solr -> ../init.d/solr
/etc/rc4.d/K20solr -> ../init.d/solr
/etc/rc5.d/K20solr -> ../init.d/solr
Waiting up to 30 seconds to see Solr running on port 80 [\] Still not seeing
Solr listening on 80 after 30 seconds!
(This is followed by several lines of INFO from the log. The only WARNs I got
are below)
970 WARN (main) [ ] o.e.j.s.SecurityHandler
ServletContext@o.e.j.w.WebAppContext@2286778{/solr,file:///opt/solr-6.0.0/server/solr-webapp/webapp/,STARTING}{/opt/solr-6.0.0/server/solr-webapp/webapp}
has uncovered http methods for path: /
1102 WARN (main) [ ] o.a.s.c.CoreContainer Couldn't add files from
/var/solr/data/lib to classpath: /var/solr/data/lib
In the "solr-800-console.log" I found the same log entries, plus the following:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:214)
at org.eclipse.jetty.start.Main.start(Main.java:457)
at org.eclipse.jetty.start.Main.main(Main.java:75)
Caused by: java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
at
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:384)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1510)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1435)
... 7 more
IF I execute the exact same command, but with port 8983 instead of 80, no
issues!
Tried: ./install_solr_service.sh solr-6.0.0.tgz -i /opt -d /var/solr -u solr -s
solr -p 8983
Result: Solr server on port 8983 (pid=10503). Happy searching!
This led me to question if this was just an issue with port 80...
IF I do as you suggest, and using the successful port 8983 installation, change
the port assignment in /etc/default/solr.in.sh to 80 while Solr is stopped,
then start Solr, I get the exact same log dump to the screen and failure to
start Solr.
IF I change the port assignment back to 8983, no issues - happy searching!
IF I change the port assignment to 81, same screen dump/failure to load as with
port 80.
IF I change the port assignment to 800, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 8000, no issues - happy searching!
IF I change the port assignment to 999, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1000, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 7000, no issues - happy searching!
IF I change the port assignment to 4000, no issues - happy searching!
IF I change the port assignment to 2000, no issues - happy searching!
IF I change the port assignment to 1500, no issues - happy searching!
IF I change the port assignment to 1001, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1250, no issues - happy searching!
IF I change the port assignment to 1100, no issues - happy searching!
IF I change the port assignment to 1050, no issues - happy searching!
IF I change the port assignment to 1025, no issues - happy searching!
IF I change the port assignment to 1015, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1020, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1021, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1022, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1023, same screen dump/failure to load as
with port 80.
IF I change the port assignment to 1024, no issues - happy searching!
Based on the above, it appears that port 80 itself is not special, but rather
that Solr does not play nice with any port below 1024. There may exist an upper
limit, but I did not test for that since my goal was to assign the application
to port 80.
For the record, there are no other listeners listening to port 80. The only
listeners are 53 for dnsmasq and 631 for cupsd on my system. Also, I have
successfully run Solr on port 80 on all 2.x-4.9.1 installations. I never go
around to upgrading to 5.x, so I do not know if there are issues with low ports
and that version.
Any insight as to why Solr 6.0.0 does not play nice with ports below 1024 would
be appreciated. If this is a "feature" of the application, it'd be nice to see
that in the documentation.
Thanks Shawn!
-Teague
-----Original Message-----
From: Shawn Heisey [mailto:apa...@elyograg.org]
Sent: Tuesday, May 31, 2016 4:31 PM
To: solr-user@lucene.apache.org
Subject: Re: Alternate Port Not Working for Solr 6.0.0
On 5/31/2016 2:02 PM, Teague James wrote:
> Hello, I am trying to install Solr 6.0.0 and have been successful with
> the default installation, following the instructions provided on the
> Apache Solr website. However, I do not want Solr running on port 8983,
> I want it to run on port 80. I started a new Ubuntu 14.04 VM,
> installed open JDK 8, then installed Solr with the following commands:
> Command: tar xzf solr-6.0.0.tgz solr-6.0.0/bin/install_solr_service.sh
> --strip-components=2 Response: None, which is good. Command:
> ./install_solr_service.sh solr-6.0.0.tgz -p 80 Response: Misplaced or
> Unknown flag -p So I tried... Command: ./install_solr_service.sh
> solr-6.0.0.tgz -i /opt -d /var/solr -u solr -s solr -p 80 Response: A
> dump of the log, which is INFO only with no errors or warnings, at the
> top of which is "Solr process 4831 from /var/solr/solr-80.pid not
> found" If I look in the /var/solr directory I find a file called
> solr-80.pid, but nothing else. What did I miss? Previous versions of
> Solr, which I deployed with Tomcat instead of Jetty, allowed me to
> control this in the server.xml file in /etc/tomcat7/, but obviously
> this no longer applies. I like the ease of the installation script; I
> just want to be able to control the port assignment. Any help is
> appreciated! Thanks!
The port can be changed after install, although I have been also able to change
the port during install with the -p parameter. Check /etc/default/solr.in.sh
and look for a line setting SOLR_PORT. On my dev server, it looks like this:
SOLR_PORT=8982
Before making any changes in that file, make sure that Solr is not running at
all, or you may be forced to manually kill it.
Thanks,
Shawn
