I am getting this error on an existing server. No configuration change. Suddenly, it happened. The log shows nothing, except something similar to the following:
10.10.10.11 - - [28/Oct/2011:01:01:08 +0800] "POST /notexist HTTP/1.1" 500 50 "-" "PECL::HTTP/1.7.1 (PHP/5.3.8)"
Until now I figured out that it is occurring only while using HTTP POST, it does not seem to be related to any CGI or PHP script.
I've recompiled Apache but the problem still exists. I wrote a script to visit a none exist URI of the server by using GET and POST. While requesting a GET, apache response 404, but for a POST, its response is a 500 error immediately.
Can anyone let me know what can I do?
I am using FreeBSD and the Apache is compiled by using event MPM.
Thanks in advance for any help.
PS. I've found it is related to subversion 1.7.1, While I reinstalled subversion 1.6.17 port, Apache seems to be working again. I am sorry to post this question here, maybe I should report this problem to FreeBSD subversion port administrator. It's weird because it doesn't happen when I upgrade to subversion 1.7.1, and it happened when there is no configuration change.
See http://svn.haxx.se/users/archive-2011-10/0457.shtml. It is a confirmed bug in Subversion 1.7.0 and 1.7.1. It's fixed in Subversion trunk with r1187695 which is proposed to be included in a following 1.7.x-release (see http://svn.apache.org/repos/asf/subversion/branches/1.7.x/STATUS).
Related
Error 1053 - Service do not respond to the start or control request in a timely fashion
I am installing solr 9.1.1 version using nssm. The path to executable was repeatedly setting to nssm.exe path. But I explicitly changed to solr.cmd path.
Now I am getting another error - Error 1053 - Service do not respond to the start or control request in a timely fashion
Path seems fine. I don't find any issue and don't understand why it is happening.
I was able to solve the error. The issue was I downloaded wrong package.
Downloaded latest from https://solr.apache.org/downloads.html.
earlier package was incomplete - without required jar files.
so downloading new package worked.
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>
Google compute engine console return 399 error code already asks my question but the solution is not as suggested there. Since the URL is little old starting a new thread.
I am trying to do a wget using:
wget https://console.developers.google.com/m/cloudstorage/b/m-lab/o/ndt/2012/05/23/20120523T000000Z-mlab1-ams01-ndt-0000.tgz
I see the error:
Resolving console.developers.google.com (console.developers.google.com)... 216.239.32.27
Connecting to console.developers.google.com (console.developers.google.com)|216.239.32.27|:443... connected.
HTTP request sent, awaiting response... 399 Internal Server Error
2014-08-26 20:02:18 ERROR 399: Internal Server Error.
I am new to Linux commands so wanted to know if am missing something obvious.
The address works when I use Chrome downloader but fails with wget with me as well
I have never seen this behaviour before
You can also use cURL to download files, I used the -v switch and got a dns error(no idea why)
curl -v http://console.developers.googlO.com/m/cloudstorage/b/m-lab/o/ndt/2012/05/23/20120523T000000Z-mlab1-ams01-ndt-0000.tgz
We cannot download with traditional tools we have to use gsutil utility provided by google, using which automation is possible.
You need to use the following URI pattern:
http://storage.googleapis.com/<bucket>/<object>
In this case, you can download that file using the command:
wget http://storage.googleapis.com/m-lab/ndt/2012/05/23/20120523T000000Z-mlab1-ams01-ndt-0000.tgz
(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!
I have an issue loading xdebug in apache server.
Here are my settings:
Apache 2.2.11
MySQL 5.1.36
PHP 5.2.0
Windows 7
Wampserver 2.0
php -i and php -m show that the xdebug module php_xdebug-2.1.0RC1-5.2-vc6.dll is installed.
However phpinfo() does not show that xdebug is installed. I have tried starting apache as a service, through the Wampserver UI, and by running httpd directly (as administrator) and I have checked permissions on the php_xdebug-2.1.0RC1-5.2-vc6.dll file.
There are no warnings in the logs. In the apache error log I get:
[Thu Jun 24 11:20:55 2010] [notice] Apache/2.2.11 (Win32) PHP/5.2.0 configured -- resuming normal operations
Has anyone any ideas?
Thank you,
John
I already do like you said but nothing happens
Using WAMPSERVER 2.1 , php_xdebug-2.1.0-5.3-vc6.dll (however I renamed it becoming php_xdebug.dll)
In php.ini, I also modified as instructions
extension=php_xdebug.dll
...
zend_extension = "C:/wamp/bin/php/php5.3.3/ext/php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"
After starting the server again, there are no error in Apache log, everything seems work normal.Still do not see any information about xdebug from phpinfo. I totally gave up :(
Any ideas for my case, appreciated that.
I solved my issue as I was using wampserver2.0 and naively assumed I could use c:\wamp\bin\php\php{version#}\php.ini to affect my configuration.
In actual fact one must use c:\wamp\apache\Apache{version#}\bin\php.ini to configure php on the wamp server.
Hope this helps anyone else who might one day tear their hair out over this.
John