PhpED 19.3 on local Windows PC was working with PHP 7.4 on remote Centos 7, however, having issues after upgrading to PhpED 19.5 and PHP 8.

Linux user "michael" use public keys on the windows PC instead of a password, and user "password_user" uses a password. I am currently logged via putty using michael account and the public key. My windows PC IP is 11.22.33.44 and my server's IP is 44.33.22.11.

I get different results when using using either Linux user michael or password_user as the Tunnel (SSH) account, and even more strange get different results if I delete the michael account from PHPed and then use the password_user account. Potentially, also related to which account is used for the Terminal account, but not sure.

On Run targets dialog, both HTTP and CLI is checked. Starting off both the Terminal Account and Tunnel (SSH) account is both michael which uses keys instead of a password.



But Checking php installation in CLI (console) mode hangs at the "running remote php-cli" step, and the detail tab just repeats for hours.


The Details tab:


Clicked Next and skipped and got following error when Checking debugger installation in HTTP (web server) mode:

And then when Checking debugger installation in CLI (console) mode, and I get the same hanging for hours when checking php-cli PHP installation.



When using another user, I get SSH tunnel errors. Not positive, but appears that PHPed is also sending my michael user to the remote server.

Checking debugger installation in HTTP (web server) mode first shows a SSH tunnel failed error and then has the same error as when using user michael.



And similarly checking debugger installation in CLI (console) mode first shows a SSH tunnel failed error and then has the same hanging as when using user michael.



And then if I delete user michael from PHPed, I think I get the same results when using michael.

The following is journalctl outputs for the various scenarios. Note that I sometimes get different results if I start when a service is using port 7869.



Terminal Account and Tunnel (SSH) account is both password_user which uses a password and the michael account which uses keys instead of a password is still in my list of PhpED accounts.




Terminal Account and Tunnel (SSH) account is both password_user which uses a password, and I removed the michael account which uses keys instead of a password.




phpinfo() shows:



Please provide any help. Thanks!!!

you may want to read this http://forum.nusphere.com/debugger-error-16-timeout-t10785.html



if you're using ssh tunnel, no matter with password or public key, you have to use unique port -- because all these ports will open on the same server's interface with 127.0.0.1 address. Obviously the same debugger port won't open 2nd time.
Update Tools->Settings->Run & Debug / Settings -> Debugger port



Can you try to set standard Linux prompt in .profile / .bash_profile?[/quote]

Thanks dmitri but still not working.


No, but just did (shown below)


Where do I change debugger.connect_timeout_seconds? Is this the same thing as "Debugger startup timeout"? Note that the default value is 15 and not 5 (see below screenshot).


Are you telling me to check "Listen on local host only" as shown on below screenshot?

On a related note, attempting to get things working, I opened port 7869 on my firewall. Even though it is being listened to, telenet and yougetsignal.com both say it is not opened. Doesn't really matter, but just making sure I don't need 7869 open.



The previous post must have been when I was using a user without a home. Changing users, I get the following. Is this what you requested me do?


Before making changes, settings were as follows:


Under Tools->Settings->Run & Debug / Settings, I changed Debugger startup timeout from 15 to 30, checked Listen on localhost only, unchecked Enable IPv6, but still shows the same. Then I created a brand new workplace, made setting changes, added a new project, and no change. Note that Settings do not seem to get propagated to even a new project (Debugger startup timeout still showed 15 and had to change it here as well) and I can't find were to change the other two settings under project. Also, not that it matters, but the debugger is still listening on all addresses and for IPV6.


So, per above, SSH tunnel as well as SSL is good, but the debug session did not start. What does this mean? Are we talking about a PHP session (storing data) and maybe they are not set up right? What type of checking is expected for the following (and what is AV?)?

1. please check php installation,
   
2. check your AV and firewall software,
   
3. and make sure that PhpED is allowed to connect web server and send HTTP requests.
   
4. Also make sure that the IDE (dbglistener.exe) is allowed to accept incoming connections on TCP/7869 port.
   
5. Also make sure that SSH tunnel for debugger is configured to the server where you're about to run and debug php
   

Thanks!

EDIT Additional information - I don't know if it matters but maybe related to how PHP is configured? I am using php-fpm (remi distro) with Apache and use pools. Before updating to the new PhpED, I had PHP 7.4 as the default and it used /etc/httpd/conf.d/php.conf, /etc/php-fpm.d/*conf, and PHP 8 (or 7.3) use /etc/opt/remi/php80/php.ini, /etc/opt/remi/php80/php-fpm.d/*conf, etc). Note that it is also listening to a socket and not an IP. This configuration worked perfectly the earlier PhpED version. When I upgraded to PhpED to all PHP 8, I also made PHP_POOL_DEFAULT use PHP8, got rid of PHP80_POOL, and added PHP74_POOL

we're talking about debugger module, it's what connects back to the IDE, so it's in php.ini, on your server

Ah, thank you. My php.ini currently shows the following. Note that the PhpED wizard told me to add slightly different content to php.ini, but after I got the errors, added a few lines that were on my previous build which worked. If anything looks bad, please let me know, otherwise I will give it a try when I get home today. Thanks

Looks correct.

Short note about filters:

You never need server's ip here. In case if you work with server through SSH tunnel(s) all you need is localhost and its numerical representation in IPv4 and IPv6 variants.
In case if you connect directly, you workstation IP address(es) should be added.


If your team has 2 developers and you assigned two ports, you have to list them there, like
debugger.ports=7869, 7870
Note that 10000/16 allows range of ports from 10000 to 10015. It does NOT opens the ports on your server, it allows debugger module to use these ports when it connects to the client(s).

Thank you dmitri for the additional info regarding filters.

Changed debugger.connect_timeout_seconds to 30 but no change.

Any thoughts on my earlier post about what debug session did not start (dbg error =-16) means, whether having PHP listen to sockets has an impact, etc?

Sorry to hear the issue still not resolved.
Regarding your previous question:

No I meant you have to use port A while you colleague should use port B, like 7867 for you and 7868 for him.
You'd do this on your client side (in the IDE), and on the server -- by allowing debugger to use these ports.
As of listen of local host only, yes, it's enough if tunnel is used and you don't need UPnp port mapping.


Debugger does not open any ports on your server. You don't need to open any ports on your server, except regular ssh and web ports if you're using web and ssh of course.

Debugger is listening on your development (client) computer. What makes port used on your server is ssh tunnel. With tunnel connections is established in the following way:

your sever:[php script, debugger module] => {localhost:7869, sshd} <===ssh communication===>
your client: <===ssh communication===> {localhost:7869, dbglistener.exe} <=> IDE

Without ssh tunnel it's connected in the following way:

your sever:[php script, debugger module] === public network ===>
your client: {public ip:7869} ==> {optionally nat port forwarding on your router} ===> {internal IP:7869, dbglistener.exe} <=> IDE



I managed to reproduce this issue with running debugger in remote terminal. Fix will be available soon.
But it has nothing to do with error -16 you reporter before.

Glad you reproduced the running debugger in remote terminal issue.

The part about ssh tunnels makes sense.

Note that I get errors such as the following after a tunnel using port 7869 has been established and then I change SSH accounts. This is to be expected and that I need to kill the process on the given port to make it available, right?



I've tried different combinations of running php-fpm and apache as different users with no change. Obviously, no need to have the ssh account use any specific user, right? Also, terminal accounts are just for cli mode, right? Does the following look as expected? Note that there are two processes where php-fpm is using user apache.


Just to make sure, you have tested using php-fpm and not just mod_php, right? Also, tested running PHP-FPM over an Unix Socket and not just a TCP/IP Socket, right?

What does Error: (-134) debug session did not start (dbg error=-16) mean? Am I able to access any logs or do any tests to determine why?

Thanks

I can think of two possible reasons for that. First is very obvious -- you and your colleague are using the same debugger port. As I mentioned above, you'd use different ports.
2nd reason is less obvious -- if ssh TCP connection died, but sshd hasn't recognized it yet and you're coming in with new session.
In this case you have two options:
* configure SSHD to run keep-alive (at L5 level). In this case it will eventually detect that session is dead and will terminate it
* kill sshd child process that is listening on the port.


no need from debugger perspectives, but might be better from security perspectives.


yes, as long you want to run CLI remotely right in the IDE. You can do this manually at any time, like `DBGSESSID='1@localhost:7869;d=1' php myscript.php`. In this case you don't need terminal account in the IDE. Putty or secureCRT would be enogh and you can try it right away, no need any fixes from me and no need any prompt changes.


perhaps -n option is needed -- it works somewhat faster then.


if it's single-threaded (non-TS) module, you may need much more than just two, depending on web load.
if it's multi-threaded (TS) module, two looks ok.


it's irrelevant to -16 problem.

Thank you dmitri,


I am the only user and unless I have unknown colleagues (let me know if you have reasons to think I do!), this does not seem like an issue as it is expected to get this error if another service is already listening to a given port. BTW, the only time this comes up is if I change the ssh account in the wizard but if I change it on properties, the phped local client must tell the remote server to kill the connection and no error.


Just grasping at straws. But something needs to be relevant. Earlier version worked great. Maybe something dumb on my side, but I have checked multiple times and think/hope I am right. How can I get clues on what is causing the debug session not to start, and what does the "debug session" really mean?

I removed the latest build of PhpED off my windows PC and installed the old 19.3 (Build 19334, 64 bit) version I still had in my downloads folder, and replaced dbg-php-7.4.so with the version used by 19.3, and all works again. I made zero other changes which makes me believe that my server is configured correctly.

I then upgraded to the last build of PhpED and updated dbg-php-7.4.so, and have the same error.

One think I noticed between these two attempts was my list of accounts were different, and I think the issue is somehow my data on the windows machine got corrupt and specifically it is related to accounts (when trying to get php8 working, phped prompted me that I couldn't delete a default account but allowed me to do so).

I then removed the new version, reinstalled old version, exported users, upgraded to new version, deleted all accounts, imported new accounts and still error.

I then removed the new version, deleted C:\Program Files\NuSphere and C:\Program Files (x86)\NuSphere, and made backup and then deleted C:\Users\michael\Documents\NuSphere, C:\Users\michael\AppData\Local\NuSphere, and C:\Users\michael\AppData\Roaming\NuSphere. I then reinstalled the new version and it says it can't find my last workspace (Evidently, I didn't delete all remnants of phped). I also noticed that Project Properties/Project/Content also still shows signs of an old account which shouldn't exist anymore. I copied my backed up copy of Documents\NuSphere\Projects (maybe a bad idea?). I've tried different options spanning from adding existing accounts or starting from fresh, but still the same errors.