Is there a way to quickly load / unload xdebug from Apache?
At the moment, I:
open up php.ini
comment / uncomment the 4 xdebug-related lines
restart Apache
which takes time.
Depends on the version of PHP you are using. If you are on 5.4+, you should be able to run this:
# php5dismod xdebug && apachectl -k graceful
And to enable:
# php5enmod xdebug && apachectl -k graceful
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
I have been trying to set up remote (virtual box server) debugging with phpstorm. When I press the debug button phpstorm just waits indefinitely for a connection. I've been looking for a solution for a couple days, and cannot get any varying results.
These are my phpstorm settings:
Host: mywebsite.dev
Port: 9000
Debugger: Xdebug
pathmapping: /public <--> /index.php
These are my xdebug params in php.ini
xdebug.remote_enable=on
xdebug.remote_autostart=off
xdebug.remote_handler=dbgp
xdebug.remote_connect_back=on
xdebug.remote_port=9000
xdebug.default_enable=on
xdebug.remote_mode=req
xdebug.remote_log=/var/log/xdebug/xdebug.log
Please let me know if you need anymore information. Thanks in advance!
This tutorial worked for me in Ubuntu
http://confluence.jetbrains.com/display/PhpStorm/Xdebug+Installation+Guide
I notice your php.ini looks a bit different. Here is mine :
[Xdebug]
zend_extension=<full_path_to_xdebug_extension>
xdebug.remote_enable=1
xdebug.remote_host=<the host where PhpStorm is running (relative to your site!)>
xdebug.remote_port=9000
And that was it.
Answering an old post for the heck of it...
You also need to edit you 20-xdebug.ini file
sudo nano /etc/php5/conf.d/20-xdebug.ini
The line zend_extension=xdebug.so should already be there. Add the following lines :
zend_extension=xdebug.so
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.scream=0
xdebug.cli_color=1
xdebug.show_local_vars=1
There might be path mapping issues as well.
If you go in run|web server debug validation … do you get error messages ? If so, that’s a clue to what you still need to solve.
You also have to set the key to your xdebug extension in your browser.
Browsing the hints when I write this message it seems this is a tough question with all kind of patches, but no clear answer ... Anyway, I try my chance, here it is.
I'm using Eclipse Helios PDT on Ubuntu 10.04, with XDebug and the corresponding section in php.ini as following:
xdebug support enabled
Version 2.0.5
Supported protocols Revision
DBGp - Common DeBuGger Protocol $Revision: 1.125.2.6 $
GDB - GNU Debugger protocol $Revision: 1.87 $
PHP3 - PHP 3 Debugger protocol $Revision: 1.22 $
Directive Local Value Master Value
xdebug.auto_trace Off Off
xdebug.collect_includes On On
xdebug.collect_params 0 0
xdebug.collect_return Off Off
xdebug.collect_vars Off Off
xdebug.default_enable On On
xdebug.dump.COOKIE no value no value
xdebug.dump.ENV no value no value
xdebug.dump.FILES no value no value
xdebug.dump.GET no value no value
xdebug.dump.POST no value no value
xdebug.dump.REQUEST no value no value
xdebug.dump.SERVER no value no value
xdebug.dump.SESSION no value no value
xdebug.dump_globals On On
xdebug.dump_once On On
xdebug.dump_undefined Off Off
xdebug.extended_info On On
xdebug.idekey no value no value
xdebug.manual_url http://www.php.net http://www.php.net
xdebug.max_nesting_level 100 100
xdebug.profiler_aggregate Off Off
xdebug.profiler_append Off Off
xdebug.profiler_enable Off Off
xdebug.profiler_enable_trigger Off Off
xdebug.profiler_output_dir /tmp /tmp
xdebug.profiler_output_name cachegrind.out.%p cachegrind.out.%p
xdebug.remote_autostart Off Off
xdebug.remote_enable Off Off
xdebug.remote_handler dbgp dbgp
xdebug.remote_host localhost localhost
xdebug.remote_log no value no value
xdebug.remote_mode req req
xdebug.remote_port 9000 9000
xdebug.show_exception_trace Off Off
xdebug.show_local_vars Off Off
xdebug.show_mem_delta Off Off
xdebug.trace_format 0 0
xdebug.trace_options 0 0
xdebug.trace_output_dir /tmp /tmp
xdebug.trace_output_name trace.%c trace.%c
xdebug.var_display_max_children 128 128
xdebug.var_display_max_data 512 512
xdebug.var_display_max_depth 3 3
I've been using Eclipse for PHP development without any problem so far, but never used debugging. When I launch the project in debugging mode I get the application correctly launched in the browser in the background, my by Debug/PHPDebug perspective is empty, while in the Eclipse console I have the message in the Title of this posting.
Thanks for any help
If Eclipse is stopping at 57%, then the remote debugging process couldn't be started. This might the case, when...
You didn't enable remote debugging in the file /PHP/php.ini:
xdebug.remote_enable=on
the remote host ip address (client which starts debug session (your IDE)) isn't correct:
xdebug.remote_host=IP_ADDRESS
Instead of defining the remote hosts ip address you can enable "multihost" remote debugging using:
xdebug.remote_connect_back=1
Also checkout the xdebug documentation for all settings: http://xdebug.org/docs/all_settings
I was struggling to setup xdebug and eclipse for an age.
I use ubuntu 12.04 on a 32bit system.
To setup the latest version of eclipse (juno) and the lamp tech stack i can strongly recommend this tutorial. There's a very good guide for setting up virtual hosts, too - script included.
Instead of following their section on installing xdebug, rather use xdebug's custom installation instructions referred to by #hakre in a related post.
Once xdebug shows up in the phpinfo output, you can continue by setting up eclipse for xdebug as described in the tutorial mentioned before.
If it still doesn't work make sure you
have read the answer above
xdebug's port is free and matches eclipse's debug configuration -> server tab -> server section -> configure button (9030 by default!)
and try
cutting the quotes from the zend_extension property within your php.ini file
putting all your xdebug-settings in your php.ini file - i dont have a xdebug.ini file in use.
repeating the filename within eclipse debug-configuration -> server tab -> url section -> last input field as shown below.
I found the problem for me was related to a specific browser, Firefox, and possibly due to an update of java to 7_21.
See my solution here
Eclipse, XAMPP, xDebug - waiting for XDebug session - stays in 57%
I had the same issue and searched for ages trying to fix it! I verified everything with my remote host, my port listening, and my Eclipse settings. I finally found the problem was that I needed to specify the IDE for XDebug in my php.ini, like:
xdebug.idekey=ECLIPSE_DBGP
Try edit the php.ini at: wamp\bin\apache\Apache2.4.4\bin
xdebug.remote_enable = on
xdebug.remote_host="localhost"
xdebug.remote_connect_back=1
I had the ame issue - editing the php folder php.ini when using WAMP seems to be not enough.
I had the exact same problem after I made a custom php build which accidentally replaced the original apache php module:
/usr/lib64/httpd/modules/libphp5.so
/usr/lib64/httpd/modules/libphp5-zts.so
To me, the fix is:
sudo rpm -e --nodeps php
sudo dnf install php
sudo service httpd restart
I found that for me it was the missing xdebug.idekey=ECLIPSE_DBGP in c:>\php\php.ini
Anyway this is my current php.ini configuration for xdebug, note I've not set the remote address:
[xdebug]
zend_extension=C:\php\ext\php_xdebug-2.9.6-7.3-vc15-nts-x86_64.dll
xdebug.remote_enable=1
xdebug.remote_connect_back=1
xdebug.remote_handler=dbgp
;xdebug.remote_host=127.0.0.10
xdebug.remote_autostart=1
xdebug.remote_port=9000
xdebug.show_local_vars=1
xdebug.expose_remotely=always
xdebug.default_enable=1
xdebug.idekey=ECLIPSE_DBGP
My environment:
W10 x64, php7.3.18 non-threadsafe, IIS as webserver
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
Something that I've noticed recently on two different machines is that Apache2 installed via MacPorts seems to have stopped launching when I boot up. The honest truth is that I can't swear it did so before, but it's something I think I'd notice because installing the LaunchDaemon is part of my install process. In fact, if I try to reload the LaunchDaemon, it fails:
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist
org.macports.apache2: Already loaded
Unless I start Apache manually (using sudo apachectl restart), grep'ing for either "apache2" or "httpd" in my process list only produces this:
$ sudo ps -ef | egrep "apache2|httpd"
0 52 1 0 0:00.06 ?? 0:00.08 /opt/local/bin/daemondo --label=apache2 --start-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart ; --pid=none
1410639199 6960 6792 0 0:00.00 ttys001 0:00.00 egrep apache2|httpd
Looks like the daemon itself is in place, but no executable. As far as I know/can tell, the relevant executables (httpd and apachectl) are executable by everyone.
Has anyone else noticed this? Any ideas?
UPDATE
As requested below, I did execute launchctl list. The list is long and I'm not sure how to snip it, but suffice to say that no org.macports.* items are listed. That in itself is interesting because my MySQL daemon is loaded the same way. It works, but also doesn't appear in the list. Let me know if the entire output is really needed.
UPDATE
I assumed that I had executed launchctl list under sudo, but prompted by mipadi's comment below, I tried again ensuring that I did so and I assumed incorrectly. When executed under sudo, the MacPorts items appear:
51 - org.macports.mysql5
52 - org.macports.apache2
I'm not sure whether that will help, but it's a little more info nonetheless.
UPDATE
I've asked a different, but related, question at LaunchDaemons and Environment Variables. I'll update both questions as I learn more.
UPDATE
Today, based on mailing list input, I tried using a wildcard home directory. Academically, it's a little more inclusive than I'd like, but the practical reality is that I'm the only one using this computer; certainly the only one who'd have Apache config files laying around.
Include "/Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf"
Include "/Users/*/Library/Application Support/MacPorts/apache/conf.d/*.conf"
Unfortunately...
httpd: Syntax error on line 512 of /opt/local/apache2/conf/httpd.conf: Wildcard patterns not allowed in Include /Users/*/Dropbox/Application Support/apache/conf.d.osx/*.conf
I found my answer to this problem here:
https://trac.macports.org/ticket/36101
"I apparently fixed this when changing my local dnsmasq config. In /etc/hosts I added my servername (gala) to the loopback entry:
127.0.0.1 localhost gala
and then I changed ServerName in /opt/local/apache2/conf/httpd.conf to match:
ServerName gala
Apache now starts at boot for me."
Since I now know why Apache has stopped loading on startup, I'm going to articulate that answer and mark this question as answered. The reason Apache has stopped launching on boot is that I'm trying to share an httpd.conf file across systems. The config file needs to Include files from directories that exist within my home directory. Since the home directory is different on each machine, I was trying to reference the ${HOME} environment variable.
This works fine when manually starting after the machine is booted, but fails on startup because the environment variable isn't yet set. As mentioned above, see this question for more information.
Rob:
Had the same problem: "sudo launchctl load -w ..." started Apache2 while I was logged in, but did not work during startup (the "-w" should have taken care of that). Also, as you noticed, the daemon seems to be registered with launchctl. It will show up with "sudo launchctl list" and another "sudo launchctl load ..." will result in the error message.
I played with "sudo port load apache2" and "sudo port unload apache2", but could not get httpd running on reboot.
In the end, I got rid of the MacPorts startup item: "sudo port unload apache2", checked with "sudo launchctl list" that org.macports.apache2 is no longer registered for startup.
Afterwards, I followed the steps on http://diymacserver.com > Docs > Tiger > Starting Apache. I only had to adapt the path from /usr/local/... to /opt/local/...
Now the MacPorts Apache2 is starting fine with every reboot.
Good luck, Klaus
I found that my MacPorts apache2 was not starting on boot because of an “error” in my httpd.conf.
I was using
Listen 127.0.0.1:80
Listen 192.168.2.1:80
Listen 123.123.123.123:80 # Example IP, not the one I was really using
And in Console.app I was seeing
4/8/12 4:59:06.208 PM org.macports.apache2: (49)Can't assign requested address: make_sock: could not bind to address 192.168.2.1:80
4/8/12 4:59:06.208 PM org.macports.apache2: no listening sockets available, shutting down
4/8/12 4:59:06.208 PM org.macports.apache2: Unable to open logs
I tried adjusting permissions on all the log folders (despite the fact that logs were being written just fine when I manually started apache2) and that didn't help.
Even though the Apache Documentation for Listen clearly states
Multiple Listen directives may be used to specify a number of addresses and ports to listen to. The server will respond to requests from any of the listed addresses and ports.
I decided to try switching back to just using
Listen 80
And after doing so apache2 is starting on boot with no errors or warnings.
If you're using Subversion with Apache, you may find that Apache is not starting because the mod_dav_svn.so file has moved to /opt/local/libexec. You'll need to adjust your Apache startup files to account for the new location of this file.
In newer versions of MacPorts you can run sudo port load apache2 to instruct MacPorts to take care of the launchctl setup and automatically start the process. To stop the process run port unload.
After loading check /opt/local/apache2/logs/error_log for errors, including configuration issues.
In addition to my previous answer I have also found that sometimes Apache fails to start because something else with the system is not yet ready.
On one OS X Server machine I also use the DNS to create a “internal only” DNS name for the machine and that name is used in my Apache configuration. Sometimes when Apache tries to start the DNS server is not yet ready and Apache fails to load because the hostname isn’t valid.
I have also seen this on other non-Server systems without local DNS as well where something else required by Apache must not be ready yet.
One thing that has worked is to edit the apache2.wrapper located at /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper that MacPorts’ daemondo uses to start up Apache.
Edit the Start() function to add a sleep command to wait a bit before launching Apache.
Original (Lines 14-17 on my machine)
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && /opt/local/apache2/bin/apachectl start > /dev/null
}
With wait time added
Start()
{
[ -x /opt/local/apache2/bin/apachectl ] && sleep 10 && /opt/local/apache2/bin/apachectl start > /dev/null
}