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
Related
I am trying to install CKAN on my local computer using Ubuntu 14.04 LTS.
I followed the instructions for installing from source found here and I try to check if solr is running by visiting http://localhost:8983/solr/.
I can see that Jetty is running because when I visit http://localhost:8983 I see that it is up.
I added the jdk as follows:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk-amd64
I am getting a 500 error when i try to open the solr page:
HTTP ERROR 500
Problem accessing /solr/index.jsp. Reason:
JSP support not configured
Powered by Jetty://
Any ideas? Should I redo the whole thing from the start?
Edit/Update
I just couldn't do anything with this installation. The bigger problem was that installation files were meshed up! I tried to install tomcat/solr instead of jetty/solr and things went sour. So I just created a VM and did a fresh install there. For anyone interested I did a tomcat/solr installation following this and a CKAN installation following this (with out of course the solr instructions). Also, for some reason the CKAN installation has commented out the solr URL, so even if it is right, I had to delete the comment.
A fix has been documented by #mstantoncook here [2939] & [1651] How to solr-jetty JSP support
Note the last comment, sudo service jetty restart
It's a Jetty BUG on Ubuntu 14.04!
There is nothing wrong with Ckan itself.
Actually, there is a bug in the libjetty-extra-java package (version 6.1.26 and newer) in Ubuntu 14.04. The bug was introduced after Jetty (in Ubuntu) has changed it's dependences from libtomcat6-java to libtomcat7-java.
You can get more info about this bug in Ubuntu Launchpad: Bug #1508562 "Broken symlinks for JSP support in libjetty-extra-java version 6.1.26-1ubuntu1.1".
The bug is already fixed on Debian, and I'm hope it will be solved in Ubuntu 14.04 soon.
There are workarounds that may work for your case
I proposed some workarounds in this bug report, and since they can be useful for the Ckan users, I'll also replicate them here.
All of them consist on use both jetty and libtomcat7-java, but adding/replacing some classes (code ported from libtomcat6, in put in the jsp-2.1-6.0.2.jar file) to the Jetty classpath.
I don't know if they have some problem. Use them at your own risk!
Workaround 1 - Install the fix package proposed by vshn
I found this workaround here: https://github.com/ckan/ckan/pull/2966
In short:
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
service jetty restart
This will install a JSP jar that works (the file will be named jsp-2.1-6.0.2.jar, but it contains classes ported from libtomcat6).
Workaround 2 - Manually install the JSP jar
Download the same JAR file that the DEB package above would install.
wget https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562/+attachment/4785985/+files/jsp-2.1-6.0.2.jar
Now, move it to a proper location inside the Jetty config dir. I did it this way:
mkdir /etc/jetty/extra-jars
mv jsp-2.1-6.0.2.jar /etc/jetty/extra-jars
And add a line like this one in the Jetty start.config file:
echo "/etc/jetty/extra-jars/jsp-2.1-6.0.2.jar" >> /etc/jetty/start.config
And:
service jetty restart
Correct solution
The correct solution is to wait for the Ubuntu Team solution. However, while waiting for this fix, you can use any of the previous workarounds (I prefer the last one).
I hope they help you!
Try this steps:
sudo mv jsp-2.1-6.0.2.jar /usr/share/jetty/lib/.
change own:
sudo chown root:root /usr/share/jetty/lib/jsp-2.1-6.0.2.jar
finally restart jetty:
sudo service jetty restart
I followed this steps and now I can see localhost:8983/solr and localhost/solr/admin
In Ubuntu 14.04 this can be fixed with:
cd /tmp
wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb
sudo dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb
sudo service jetty restart
Following http://docs.ckan.org/en/ckan-1.6/solr-setup.html#single-solr-instance
(this one a bit old, but worked perfect for me )
You will have to edit /etc/profile and add this line to the end such as this to the end (adjusting the path for your machine’s jdk install:
JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/ (or other version)
then
export JAVA_HOME
sudo service jetty start
Using OS X 10.9.1 and AMPPS 2.1 (dated 11/18/13) I can launch the Apache server, but when attempting to go to the admin or configuration pages I get 404 errors for both localhost/ampps-admin and localhost/ampps.
Where should I be looking to track down this problem?
When you close ampps and look at localhost, is it still saying "It works!"?
Mine was, which meant my mac was running its version of apache. I fixed it by killing my mac's apache and then restarting AMPPS.
Kill apache:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
I've been beating my head against this for hours.
I've come back to do some work in PHPStorm after not having used it in a couple of weeks, and for some reason the debug doesn't work any more. It used to work, but now it doesn't and I have no idea what is going on.
I'm running on Windows, using IIS, PHP version 5.3.8. The XDebug is installed, and I've set the configuration in PHP.ini as per the usual instructions.
When I run phpinfo() everything looks normal (ie. XDebug is there).
I've rechecked various settings, downloaded a slightly newer version of XDebug than I was using (Xdebug v2.2.1), but nothing seems to kick it into life.
Can someone please give me some clues as to what I can look at next?
UPDATE:
I've spent a few more hours beating my head against this, and don't seem to have gotten much further. XDebug is installed and loaded, according to phpinfo(). I turned on logging, but it doesn't really tell me much except that XDebug is indeed connecting...
Log opened at 2013-02-17 04:13:07
I: Connecting to configured address/port: localhost:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///C:/web/dbg/index.php" language="PHP" protocol_version="1.0" appid="6912" idekey="PHPSTORM"><engine version="2.2.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2012 by Derick Rethans]]></copyright></init>
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
Log closed at 2013-02-17 04:13:07
So it seems that the problem is on the PHPStorm side, but I cannot see where. I tried creating a very simple project, but could not get that to debug either.
Don't you hate it when you spend hours wrestling with something, then in desperation try something simple, and it works?
I decided to try a different port, 9001 instead of the default 9000, and it WORKED!
I now realise that I recently installed Twonky (for video streaming to my TV), and when I checked the settings, there it was... port 9000.
Had the same issue this afternoon - found this question along with several other SO questions so I thought I'd post the solution that fixed it for me.
I was missing a mapping to the file system. Which is odd because I've seen PHPStorm prompt me when they've been missing previously.
Hopefully this helps someone in the future :)
Had the same problem after updating to El Capitan. First hint to that I used is Run -> Web Server Debug Validation.
This tool from PHPStorm gave me a hint about xdebug.remote_host I'm using v-hosts and it was complaining localhost being not the correct value there. So I updated xdebug setting with xdebug.remote_connect_back=On and it worked!
Apparently if you try to debug on newer versions of xdebug you have to include this line to your xdebug-php.ini settings
xdebug.mode=debug
I had same problem and I resolved it by deleting all the watches, and then reboot phpStorm
I resolved by by myself also, cause PHP-Storm and PHP-FPM are listening same port... just kill all php-fpm port.
Had the same problem. For me I was using port 9010 for xdebug. Problem turned out to be Logitech's GHub software I recently installed for a new mouse listens on port 9010! You can use this to see what is listening on a given port on Macs:
lsof -nP -iTCP:9010 | grep LISTEN
Newer versions of PHPStorm have Debugger validation. The official PHPStorm Blog has a writeup on this feature which might help you figure it out.
One snafu for me when I set up a box with php-fpm configured is that php-fpm runs on port 9000 by default also, so I had to change the configured port in php.ini and PHPStorm's preferences to something like 9001.
For what it's worth, my current php.ini setup for xdebug:
[xdebug]
zend_extension="/the/path/to/xdebug.so"
xdebug.file_link_format="txmt://open?url=file://%f&line=%l"
xdebug.remote_enable=1
xdebug.remote_autostart=On
xdebug.remote_port=9001
xdebug.profiler_enable_trigger=1
xdebug.max_nesting_level=250
I had the same problem! I finally realized that all my configurations were correct, but on the browser side, I hadn't enabled debugging with the Chrome Browser. Each browser has their own way of enabling the debugging to start working.
I had the same issue and I tried all the solutions I could find in SO and in other sites (checked that both phpStorm and Xdebug are on the same ports, checked that I had the server mapping on the file system, reinstalled Xdebug, etc.) but eventually the problem was in the fact that we run the site on an internal server, and someone from IT changed my computer's IP address to an address which is filtered out of the allowed addresses that can be connected to that server. That's why phpStorm started to ignore the breakpoints from Xdebug.
Hopefully, this will help someone in the future and save him many hours.
Found that if xdebug log file is not writable then it could be not working. Always better to set xdebug.remote_log and make it writable.
I'm using Collabnate Subversion Edge.
I'm getting below error when trying to access URL http://localhost:3343/csvn.
Collbnate is set up on Windows Server 2008.
HTTP ERROR: 503
Problem accessing /csvn/. Reason:
Service Unavailable
Powered by Jetty://
How to solve it?
I spent two days fighting with the same problem. It turned out that CollabNet Subversion Edge 4.0.11 does not support Java 8.
The following procedure helped me make CN Subverion Edge 4.0.11 work again on Windows 7:
1) Uninstall CollabNet Subversion
2) Uninstall Java 8 (I had Java 7 and 6 side by side, so after uninstalling the 8, 7 picked up after I added it to PATH variable. It is important to add it at the very beginning of the path, otherwise Windows\System32\java.exe will be taken, which was not good for me also)
3) Install CollabNet Subverion (the important thing is to uncheck the "Run CollabNet ..." check box in the final screen. It looks like the installer is still creating files at the end and only after I have clicked OK in the final screen the needed configuration files have been created in data/conf folder.
4) Make sure that data/conf/httpd.conf file is created. If it is there, got to services (services.msc) and start server manually
Now launch the browser and navigate to localhost:3343/csvn.
Good luck.
1) Install Java 7
2) In file \csvn\svcwrapper\conf\wrapper.conf change from #wrapper.java.command.maxVersion=1.6 to wrapper.java.command.maxVersion=1.7
3) Run \csvn\svcwrapper\bat\runConsole.bat
Good luck.
Check in c:/csvn/data/logs for a log that starts with "console". Then find the error(s) and check what is wrong.
Did you try restarting the service ?
I had the same issue, CollabNet Subversion Edge version 4.0.4. In my case the problem was updating the JAVA_HOME from JDK 1.6 to JDK 1.7.
I finally resolved it changing the file:
C:\PROGRA~1\csvn\svcwrapper\conf\wrapper.conf
I changed the value of the property: wrapper.java.command:java
wrapper.java.command=C:/PROGRA~1/Java/jdk1.6.0_45/bin/java
So the csvn now runs with 1.6 as before. And it works again as a service automatically.
Good luck!!
There's an alternative issue that results in the same error: The database may get corrupted. This is what just happened to me. The above answers where not working in this case. As Subversion Edge 5.0.1 comes bundled with jre8, it would be rather strange if it weren't able to run against it.
To solve the problem, I had to patch the database (luckily, the user database c:\csvn\data\csvn-production-hsqldb.script is a plain text sql file).
Backup files in c:\csvn\data
Delete csvn-production-hsqldb.script and start the service (should come up now)
Exit the service
Save the file which is automatically recreated now
Compare your old file and the new working one
Replace every line starting with INSERT INTO QRTZ in your database with the corresponding lines from the working copy
Copy the new files to the proper place
Start the service
Hope it worked
I had this problem too. Upgrade to SubversionEdge 5.1.4 solved the issue.
We encounter this problem with CollabNet Subversion Edge 3.3.1 every time we patch our JDK 6 install (e.g. IAVM update). We need to install JDK 7 and 8 on this machine also so the installers are confusing the version information in the Windows Registry (not too much of a surprise there). Even if we update JDK 6 last, it gets weird too.
Nevertheless, it turns out the Subversion Console uses the Windows Registry to locate the Java install to launch the Console service. Updating the registry entry HKLM\SOFTWARE\JavaSoft\Java Development Kit\CurrentVersion to 1.6 and having a proper install of JDK 1.6 will restore console operation.
I've succecfully installed xdebug 2.2.0-dev and my phpinfo() shows all the options, but I can't get it work with my IDE. In my IDE when I click at the option "Listener status" I see the number "Total connections" changing when I try to debug but the script simply doesn't stop at my breakpoint nor at the command xdebug_start(). I use a reverse shell to my server but when I telnet to Port 9000 on my localhost I get the error message: Name or service not known??? What can I do? Install the stable 2.1.2? When I start lighttpd I get this warning:
Xdebug requires Zend Engine API version 220060519.
The Zend Engine API version 220090626 which is installed, is newer.
Contact Derick Rethans at http://xdebug.org for a later version of Xdebug.
There are a few things going wrong there. The big warning at the bottom only says that you have compiled Xdebug against the headers for the wrong PHP version. Do you have multiple sets of headers? If so: remove the ones you don't need.
Your telnet command is likely wrong, you use it like "telnet localhost 9000". Breakpoints not stopping is possible because you have not set-up path mappings in Komodo.