I've been working with ddev on my Drupal projects, and now want to use xdebug so I have step-debugging with PhpStorm (or really any IDE would be fine). But I can't seem to get it to stop on breakpoints. I tried to follow the instructions in ddev docs but that doesn't do get me going, and I don't know what to do next. I did:
Set the 172.28.99.99 IP address as discussed there
Enabled xdebug using config.yaml xdebug_enabled: true and ddev start (and checked with phpinfo to see that xdebug was enabled.)
Put PHPStorm in "listen for debug connections" mode
Debugging xdebug in any setup can be a little trouble, but here are the steps to take:
First, reread the docs. You may want to read the troubleshooting docs rather than this issue, since they're maintained more often.
Make sure xdebug has been enabled; it's disabled by default for performance reasons. Most people use ddev xdebug on to enable it when they want it, and ddev xdebug off when they're done with it, but it can also be enabled in .ddev/config.yaml.
Don't assume that some obscure piece of code is being executed and put a breakpoint there. Start by putting a breakpoint at the first executable line in your index.php. Oh-so-many times people think it should be stopping, but their code is not being executed.
ddev ssh into the web container. Can you ping host.docker.internal (and get responses)? If you can't, you might have an over-aggressive firewall.
In PHPStorm, disable the "listen for connections" button so it won't listen. Or just exit PHPStorm.
ddev ssh: Can telnet host.docker.internal 9003 connect? If it does, you have something else running on port 9003, probably php-fpm. Use lsof -i :9003 -sTCP:LISTEN to find out what is there and stop it, or change the xdebug port and configure PHPStorm to use the new one . Don't continue until your telnet command does not connect.
Now click the listen button on PHPStorm to start it listening for connections.
ddev ssh and try the telnet host.docker.internal 9003 again. It should connect. If not, maybe PHPStorm is not listening, or not configured to listen on port 9003?
Check to make sure that Xdebug is enabled. You can use php -i | grep grep Xdebug inside the container, or use any other technique you want that gives the output of phpinfo(), including Drupal's admin/reports/status/php. You should see with Xdebug v2.9.6, Copyright (c) 2002-2020 and php -i | grep "xdebug.remote_enable" should give you xdebug.remote_enable: On.
Set a breakpoint in the first relevant line of the index.php of your project and then visit the site with a browser. It should stop there.
A note from #heddn: If you want to have xdebug running only for fpm, phpenmod -s fpm xdebug for example, instead of running enable_xdebug.
A note from #mfrieling: If you use a browser extension like XDebug Helper which sets an IDE key, that must be the same as on the server. Since DDEV 1.10.0 "there's a real user created for you inside the web and db containers, with your username and userid" which is also used as IDE key by default. The used IDE key must be the same on the server, the browser extension/cookie sent and PHPStorm. You can change the IDE key in DDEV by creating a file .ddev/php/xdebug.ini with the following two lines (replace PHPSTORM with the value you want use:
[XDebug]
xdebug.idekey = PHPSTORM
Your followups are welcome here!
Thanks, had the same problem and adding the file .ddev/docker-compose.xdebug.yaml fixed the issue.
However, I am running on a Mac / OSX and found these additional steps worked to discover the IP address of the internal host from inside the container:
1.) Log into the web continaner ddev ssh
2.) Run ping docker.for.mac.localhost
3.) Set the returned IP address for host.docker.internal in the above yaml file.
4.) Remove and start the DDEV.
Also worth mentioning validating xdebug in PHPStorm is useful to check the config.
Careful with Macs, as they may have php-fpm running. If it's the case PHP Storm won't find the connection (as it's already taken by php-fpm).
To see if it's the case run:
lsof -i :9000 -sTCP:LISTEN
if it returns something like php-fpm, then you have this issue
Try closing it (see PHP-FPM can't be closed ).
Running it once you have fixed it (potentially restarted your mac) you should see something like this:
➜ solrpoc lsof -i :9000 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
phpstorm 512 alejandro.moreno 490u IPv6 0xaf3eef0f3233a83 0t0 TCP *:cslistener (LISTEN)
Related
I've followed the directions here, but when I run ./svc.sh run, I receive the following error:
Could not find domain for port (Aqua)
I'm SSH-ing into a box to run this command, it seems to work fine when I'm not in a headless session, but I need this to be headless and as a background service. Anyone else run into this?
I was able to resolve this, addressed here
sudo cp {/Users/xxx/Library/LaunchAgents,/Library/LaunchDaemons}/your.plist
I was able to reboot my machine without logging in and see the runner active
Solution by #futbolpal not good, because LaunchDaemons doesn't have access to keychain.
Better copy to LaunchAgents
Like:
sudo cp {/Users/xxx/Library/LaunchAgents,/Library/LaunchAgents}/your.plist
I keep getting this error on my marathon dashboard
Framework with ID 'a5a96e8c-c3f2-4591-8eb3-43f8dc902585-0001' does not exist on slave with ID '9959ba51-f6f7-448f-99d2-289767f12179-S2'.
The path to make this error occur is to click "Sandbox" next to a task on the main marathon dashboard.
The path looks something like this
http://mesos.dev.internal/#/slaves/9959ba51-f6f7-448f-99d2-289767f12179-S2/frameworks/a5a96e8c-c3f2-4591-8eb3-43f8dc902585-0001/executors/rabbitmq.6316bf0a-d089-11e5-b895-fa163e196ca3/browse
However, if I go to the slave through the slave panel, and click the framework from there, I am able to access the sandbox. The link in this case looks like the following
http://mesos.dev.internal/#/slaves/9959ba51-f6f7-448f-99d2-289767f12179-S2/browse?path=%2Ftmp%2Fmesos%2Fslaves%2Fc223b6b1-cef8-4599-8cea-b402bf20afc5-S0%2Fframeworks%2F20160108-205802-16842879-5050-1210-0001%2Fexecutors%2Frabbitmq.91b8bbf6-ceba-11e5-8047-0242ffdabb3e%2Fruns%2Fc66eb4d5-ea6d-451d-982f-6a0d29b25441
Any ideas on what I have misconfigured?
Mesos Web UI does not proxy logs through mesos-master (although it would be nice). Basically you need to be able to resolve slave's name from your browser (computer) and port 5051 needs to be open for you:
$ nc -z -w5 mesos.dev.internal 5051; echo $?
0 # port is open
It's not a good idea to leave Mesos ports open for public, so either you can:
connect via VPN
whitelist your public IP on all slaves
use CLI instead of Web UI
Using CLI is quite easy, once you set master's URI. You can install it:
pip install mesos.cli mesos.interface
Then you can list all tasks using mesos ps, or fetch stdout:
mesos tail -f rabbitmq.6316bf0a-d089-11e5-b895-fa163e196ca3
and stderr:
mesos tail -f rabbitmq.6316bf0a-d089-11e5-b895-fa163e196ca3 stderr
Note that the mesos-cli is no longer developed, similar features and much more you should be able to do with Mesosphere's DCOS CLI
I am using behat+mink. I wrote some features and am now running tests.
How can I enable xdebug to to stop on breakpoints in phpstorm when running behat tests ?
I have not tried this with Mink yet, but this is configuration that allows me to step through debugging of behat (with behat running on a remote server):
Configure your server with x-debug
Of note, since this is commandline, you need to edit the cli config under /etc/php5/cli/conf.d/20-xdebug.ini.
Set remote_host to the ip of the computer you're using PHPSTORM from
Set autostart = 1
Disable connect_back, you will initiate debugging from the server so there is nothign to connect back to
You can also do this without editing your ini by exporting values as env variables, just remember to do this each time you start a new shell (or add to your .bash_profile file):
export XDEBUG_CONFIG="remote_host=<YOUR IP>"
Configure PHPStorm's Debugger
It seems by default, PHPStorm doesn't understand remote-cli scripts, so we need to add a configuration that tells it to expect a CLI script to trigger xdebug
Open the Run Menu and select "Edit Configurations"
Click the Green "+" to to add a new configuration and select "PHP Remote Debug"
Name the Configuration (E.G. MyServer-Behat)
Under the Servers: menu, select your remote server.
If you haven't configured your remote server yet, then do this by clicking the "..." button on the right
Click the Green "+" to add a server configuration. Give it a name (E.G. MyServer) and fill in it's address under Host
Configure it's Path Mappings. This is important if the path to your source files is different on your PHPStorm computer from your server. You can see in my example that i'm relating my local checkout (~/Work/Symfony/) to my server install (/var/www/). I specifically added mappings for src, bin, web, app, and vendor by clicking in the space to the right under "Absolute path on the server" and typing in the path. I had issues just mapping the root's, so I had to add these paths to get my debugger to work.
Debug!
Once that is setup, select your configuration from the drop down in the debugging tool bar and click the bug icon (you can also use the Run menu) to start the debugger listening. This is similar to the default Telephone Button (circled in yellow), but it tells PHPStorm to use your new configuration.
Now simply run behat like you normally would from your server and your debugger should connect and stop on any breakpoints you've placed.
If you're having doubts about if it's working or not, try toggling the "Break on First Line" in the Run menu, as this should make the debugger break immediately when you run behat (in the bin/behat file)
My gitlab is on a virtual machine on a host server. I reach the VM with a non-standard SSH port (i.e. 766) which an iptable rule then forward from host:766 to vm:22.
So when I create a new repo, the instruction to add a remote provide a mal-formed URL (as it doesn't use the 766 port. For instance, the web interface give me this:
Malformed
git remote add origin git#git.domain.com:group/project.git
Instead of an URL containing :766/ before the group.
Wellformed
git remote add origin git#git.domain.com:766/group/project.git
So it time I create a repo, I have to do the modification manually, same for my collaborator.
How can I fix that ?
In Omnibus-packaged versions you can modify that property in the /etc/gitlab/gitlab.rb file:
gitlab_rails['gitlab_shell_ssh_port'] = 766
Then, you'll need to reconfigure GitLab:
# gitlab-ctl reconfigure
Your URIs will then be correctly displayed as ssh://git#git.domain.com:766/group/project.git in the web interface.
if you configure the ssh_port correctly in config/gitlab.yml, the webpages will show the correct repo url.
## GitLab Shell settings
gitlab_shell:
...
# If you use non-standard ssh port you need to specify it
ssh_port: 766
ps.
the correct url is:
ssh://git#git.domain.com:766/group/project.git
edit: after the change you need to clear caches, etc:
bundle exec rake cache:clear assets:clean assets:precompile RAILS_ENV=production
N.B.: this was tested on an old Giltab version (v5-v6), and might not be suitable for modern instance.
You can achieve similar behavior in a 2 step process:
1. Edit: config/gitlab.yml
On the server, set the port to the one you use:
ssh_port: 766
2. Edit ~/.ssh/config
On your machine, add the following section corresponding to your gitlab:
Host sub.domain.com
Port 766
Limit
You will need to repeat this operation on each user's computer…
References
GitLab and a non-standard SSH port
Easy way to fix this issue:
ssh://git#my-server:4837/~/test.git
git clone -v ssh://git#my-server:4837/~/test.git
Reference URL
I have MySQL set up correctly on my linux computer, however I want a better way to input data into the database besides terminal. For this reason, I downloaded phpMyAdmin. However, when I try to log in to the phpMyAdmin from index.php, it doesnt do anything. It seems to just refresh the page without doing anything. I am putting in the correct MySQL username and password. What is the issue?
Here is a screen shot of what it shows after I click "go".
This is a possible issue when the path to save php_session is not correctly set :
The directory for storing session does not exists or php do not have sufficient rights to write to it.
To define the php_session directory simply add the following line to the php.ini :
session.save_path="/tmp/php_session/"
And give write rights to the http server.
usually, the http server run as user daemon in group daemon. If it is the case, the following commands will make it :
chown -R :daemon /tmp/php_session
chmod -R g+wr /tmp/php_session
service httpd restart
Login fails if session folder in not writeable. To check that, create a PHP file in your web directory with:
<?php
$sessionPath = 'undefined';
if (!($sessionPath = ini_get('session.save_path'))) {
$sessionPath = isset($_ENV['TMP']) ? $_ENV['TMP'] : sys_get_temp_dir();
}
if (!is_writeable($sessionPath)) {
echo 'Session directory "'. $sessionPath . '"" is not writeable';
} else {
echo 'Session directory: "' . $sessionPath . '" is writeable';
}
If session folder is not writeable do either
sudo setfacl -R -m u:www-data:rwx <session directory> or chmod 777 sudo setfacl -R -m u:www-data:rwx <session directory>
-
I am late to the game, but on Amazon linux AMI I could not log in to phpmyadmin ... it just kept refreshing the login screen with no errors.
I have fixed with below command
sudo chmod -R 755 /var/lib/php/session
I fixed my issue on CentOS 7 with MariaDB and phpmyadmin I downloaded from offical phpmyadmin site by adding
session.save_path = "/var/lib/php/session"
to /etc/php.ini
and
chown -R :lighttpd /var/lib/php/session
I also restarted php-fpm and lighttpd after
In my case the solution was to set an Apache setting properly:
ProxyPassReverseCookiePath
This was required, because ProxyPass and ProxyPassReverse were in use, but cookie paths are not changed automatically.
It'd be great if PHPMyAdmin had shown something like session not found or anything, when password is sent with POST.
Do you have a .htaccess file in one of the parent directories that strips off index.php from the url by doing a 301 redirect?
301 redirects discard the form data and redirect you as if you didn't submit anything. So you get returned to the login page.
So you should create a local .htaccess file in the phpmyadmin directory with a single line RewriteEngine On. This will overwrite the previous rewrite rule to nothing.
You may need to clear the browser cache as Chrome aggressively caches 301 redirects.
In my case the hard drive was full.
Use df -h to check the space left on your hard drive, and if you want you can free some space by using the command sudo apt-get clean, which removes installation files.
I hope this will help some future users.
I ran these commands and it worked for me:
sudo service httpd restart
sudo service mysqld stop
sudo service mysqld start
Try searching the web for installation or setup guides for phpMyAdmin. Look at two or three of these and make sure you have covered all the required steps. (If you have already done so, please include which guides you have followed it in the question).
See if it helps to edit config.inc.php (acecoder mentioned this as well).
Check if this guide is of any help.
Which distro are you on? Try searching for the name of the distro you are using together with "phpMyAdmin guide" or "phpMyAdmin setup howto".
If you encounter errors along the way, post the error text here, if it's short (or paste via a pastebin-like site if it's long).
Are you sure that mysql is running? I had the same issue after doing a database import and filling up the volume containing the mysql database. After changing various permissions and clearing sessions, I tried to restart mysql (/etc/init.d/mysql restart) and it failed because the volume was full. After increasing /var and starting mysql successfully, I was able to log into phpmyadmin just fine.
If you have an error like:
Host 'host_name' is blocked because of many connection errors.
Login in your mysql as root and run the flush hosts command
1.- mysql -u root -p
2.- mysql > flush hosts
After this I was able to login again in phpmyadmin
phpMyAdmin will show errors when login fails. If it doesn't, it means that your setup has an error.
The most likely place to check is your php.ini settings. Since there doesn't seem to be an official list of phpMyAdmin-compatible settings, it's mostly trial and error.
Make sure you have enabled the stuff that needs to be enabled. Also check that you did not enable uncommon php.ini settings (like enable_post_data_reading = Off) because phpMyAdmin assumes them to be "the usual ones".
To ease debugging, start with a clean default php.ini file then tweak them line by line to see which setting is causing the error. (Don't forget that you need to restart your server after changing the php.ini file for the changes to take place.)
In my case it was due to an old Apache session.
Stop Apache, clear all pending sessions in your sessions.save_path directory (example: /var/lib/php/session) and restart Apache.
Make sure to set a 32 chars long random key in 'config.inc.php' in the $cfg['blowfish_secret'] value. That solved it for me.
Didn't realize I need to restart MariaDB after modifying config.inc.php:
service mariadb restart
Otherwise at least in my case changes didn't come affect. Also make sure your php session directory is writable by webserver (typically session.save_path = "/var/lib/php/session")