Starting a Debugging Session from the Command Line

Hi there,

>serverName=LocalServer

>Host: 127.0.0.1

try setting up "Host" to be the value of "serverName"  -- i.e. "LocalServer" -- I believe it meant to work this way.

P.S. Out of curiosity -- why not start/debug it from within the IDE (especially if that works)?

Still doesn't seem to work. In File->Settings->Languages & Frameworks -> PHP -> Servers->LocalServer, set "Host" to "LocalServer" (the same as the "Name" of the server), tried port both 80 and 9000.

BTW, XDebug is enabled for the CLI mode:

$ /usr/bin/php --version
PHP 7.0.26-2+ubuntu16.04.1+deb.sury.org+2 (cli) (built: Dec  7 2017 20:09:40) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.26-2+ubuntu16.04.1+deb.sury.org+2, Copyright (c) 1999-2017, by Zend Technologies
    with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans

Could you, please, give an example of a case when it works for you: all the settings that you have related to the debugging and the command that you run the program with?

The problem with starting it from the IDE is that the bug I'm trying to debug is absent in that case. So, I'm hoping it will be present if I start the command from the command line as I do when I get the bug without the debugging.

"PHP | Servers" -- it does not matter what you have got there (what server name .. or even having an entry at all)... as long as you do not use path mappings (e.g. for any symlinks etc)

export XDEBUG_CONFIG="idekey=session_name"

That's what you need to have (replace "export" by "set" for Windows). IDEKEY can be anything (PhpStorm works with any; other IDEs/editors may not).

(I have removed the text mentioning "serverName=LocalServer" that I initially wrote -- I was referring to the wrong variable)

Once you finish with debugging, you need to empty the value/remove such env variable to prevent possible debugger triggering for other scripts (e.g. "SET XDEBUG_CONFIG=" for Windows).

Possible alternative -- just add "-dxdebug.remote_autostart=1" to your parameters (worked fine for me). E.g.

/usr/bin/php -dxdebug.remote_enable=1 -dxdebug.remote_mode=req -dxdebug.remote_port=9000 -dxdebug.remote_host=127.0.0.1 -dxdebug.remote_autostart=1 /var/www/print/public/bin/magento module:enable Magento_Bundle

Or you can configure it all in php.ini (will affect ALL scripts that are executed by this PHP interpreter with that php.ini). In such case you do not need all this stuff here in command line and in theory (depends on how much you have configured in php.ini) it might be as simple as this (still using full paths here so it's more clear):

/usr/bin/php /var/www/print/public/bin/magento module:enable Magento_Bundle

The benefit of passing all those params via command line is to ensure that they are set (as they override values from php.ini).

Ok, so, I tried adding '-dxdebug.remote_autostart=1' to the command line and then 'export XDEBUG_CONFIG="idekey=PHPSTORM"', and it seemingly didn't help, but then I noticed XDebug was switched off (because of another issue I'm working on). Then I switched back on and the debugger came to life.

However, then I tried to remove '-dxdebug.remote_autostart=1' and reset "XDEBUG_CONFIG" to empty (and switching PhpStorm instances, and removing the servers in IDE), still the debugger starts in any case. Running the same command line command I ran unsuccessfully a few hours ago. So I'm still not sure precisely which settings are required to get this working. Maybe it's also got something to do with me invalidating PhpStorm's caches (due to yet another problem I had with PhpStorm).

Thanks for the advice nonetheless! If the debugging doesn't work at some point again, I'll know to come back here and see what to try.

BTW, how did you get a formatted code in here?

>Ok, so, I tried adding '-dxdebug.remote_autostart=1' to the command line and then 'export XDEBUG_CONFIG="idekey=PHPSTORM"',

You do not need both of them -- only one of them is enough (at very least for me at Windows 10 & PHP 7.0)

> but then I noticed XDebug was switched off

You can activate it via command line parameter as well -- tell PHP to load that particular extension (full path). That's what IDE can do as well -- it has separate field in PHP Interpreter settings (obviously, it works for CLI environment only).

>However, then I tried to remove '-dxdebug.remote_autostart=1' and reset "XDEBUG_CONFIG" to empty (and switching PhpStorm instances, and removing the servers in IDE), still the debugger starts in any case.

Possibly XDEBUG_CONFIG was not cleared. I'm on Windows and setting it to empty removes it. Maybe on Mac/Linux it works differently and you need to use some another command (No Mac/Linux at hand so I've never bothered to check it).

>Maybe it's also got something to do with me invalidating PhpStorm's caches

No. Xdebug still somehow sees the "debug me" flag. It's xdebug who connects to IDE .. so it must be an "issue" from his end. IDE's caches have nothing to do with this at all .. as they about search/code completion/inspections.

>BTW, how did you get a formatted code in here?

Use first button on this editor toolbar (the paragraph sign) -- it allows to select "Code" style.

Be careful though -- if you apply it to the very last line it might be difficult to get to get normal style back without resetting it.

The editor here is not the most convenient -- I would prefer markdown with a preview area (something like their Issue Tracker or StackOverflow has) -- rich HTML editing quite often is problematic in some cases (but it's easier to use by a non-technical person in general).

Yes, I had not removed "XDEBUG_CONFIG" variable. As you said, any value would do for "PhpStorm", which in my case means also a blank. So

export XDEBUG_CONFIG=

is actually as good as enabling the debugging. In order to stop it, I need either to re-login or run

unset XDEBUG_CONFIG

The option "-dxdebug.remote_autostart=1" worked, too.

Passing the "xdebug.so" didn't work though ("-z xdebug.so" gave "No such file or directory", "-z /usr/lib/php/20160303/xdebug.so" (and three other similar paths to a file with the same name) gave "undefined symbol: zend_pass_function"). But that's not a big deal, I can enable it in the ini file.

Thanks!

>As you said, any value would do for "PhpStorm",

That was about actual IDEKEY value. In your case (where whole XDEBUG_CONFIG was just an empty string) you did not provide any value for IDEKEY so default from php.ini was used (which also might be empty).

>So "export XDEBUG_CONFIG=" is actually as good as enabling the debugging.

Hmm ... so apparently you just need XDEBUG_CONFIG variable to be present -- that's enough for xdebug to recognize it as "debug me" flag... OK.

>unset XDEBUG_CONFIG

So it requires different command for removing it. Good to know.

>gave "undefined symbol: zend_pass_function".

You must be having multiple PHP installations/xdebug libraries on your system. Such error usually means that you are trying to load incompatible extension version (built for older PHP).

• "20160303" in the path tells me that it's for PHP 7.1
• PHP 7.0 should have "20151012"
• (You can see this info from the top table of phpinfo() output or "php -i")

>But that's not a big deal, I can enable it in the ini file.

If you have enabled that there .. then it should be using full or relative path there. Just cross-verify what the correct path is. Considering the above info you were just trying to load the wrong file.

OK, thanks for the explanation of xdebug.so paths! I've now added an argument "-z /usr/lib/php/20151012/xdebug.so".

If I enable xdebug.so in an ini file, a debugging session starts all right after PHP has complained that it "Cannot load Xdebug - it was already loaded" (so – from both php.ini and command line argument).

However, if I disable the ini file's xdebug.so line, then the debugging session does not start:

$ /usr/bin/php -z /usr/lib/php/20151012/xdebug.so -dxdebug.remote_enable=1 -dxdebug.remote_mode=req -dxdebug.remote_port=9000 -dxdebug.remote_host=127.0.0.1 -dxdebug.remote_autostart=1 /var/www/print/public/bin/magento module:enable Magento_Bundle
No modules were changed.

Maybe it then gets started too late and the other debugging settings have no effect.

>Maybe it then gets started too late and the other debugging settings have no effect.

Nope. PHP does not start executing the script before it reads whole config etc.

>I've now added an argument "-z /usr/lib/php/20151012/xdebug.so".

-dzend_extension=/usr/lib/php/20151012/xdebug.so

Use that instead -- works here.

Yes, with that option it works for me, too. I may even not write the full path:

-dzend_extension=xdebug.so