Remote debugging time out error

Hello,

I have the latest PyCharm version 213.5744.248 on a Debian 11 machine.

I follow the instructions of Remote Debugging with PyCharm, and specifically the second method, Remote debugging with the Python remote debug server configuration.

When I start the Debugger I get the expected "Waiting for process connection...", but when I run the script from the remote server I get the error:

socket.timeout: timed out

Some troubleshooting that I did is to check that I have the latest/correct pydevd_pycharm version. Many answers to this error mention connection problems, and specifically problems for accessing the script. How can I verify that my connection does not have any issues? Should I check the port (and if yes, how)?

The error message that I get is:

Could not connect to <IP>: <port>
Traceback (most recent call last):
File "/home/<user>/miniconda3/envs/env/lib/python3.9/site-packages/_pydevd_bundle/pydevd_comm.py", line 458, in start_client
s.connect((host, port))
socket.timeout: timed out
Traceback (most recent call last):
File "/home/<user>/<path>/main.py", line 16, in <module>
pydevd_pycharm.settrace(<IP>, <port>, stdoutToServer=True, stderrToServer=True)
File "/home/<user>/miniconda3/envs/env/lib/python3.9/site-packages/pydevd.py", line 1689, in settrace
_locked_settrace(
File "/home/<user>/miniconda3/envs/env/lib/python3.9/site-packages/pydevd.py", line 1745, in _locked_settrace
debugger.connect(host, port) # Note: connect can raise error.
File "/home/<user>/miniconda3/envs/env/lib/python3.9/site-packages/pydevd.py", line 655, in connect
s = start_client(host, port)
File "/home/<user>/miniconda3/envs/env/lib/python3.9/site-packages/_pydevd_bundle/pydevd_comm.py", line 458, in start_client
s.connect((host, port))
socket.timeout: timed out
7 comments
Comment actions Permalink

For some reason the remote server cannot connect with the PyCharm debugger. In the error that I posted above I used the port 12345 as suggested in the article, but I also checked another port to see if that was the problem. I tried also the 9922 port but got the same error.

Does anyone know what prevents the server from connecting?

0
Comment actions Permalink

I have the same issue with a Mac OS machine. Searching for the problem I found Pavel Karateev describing the Python Debug Server architecture and it appears that the frontent of the debugger cannot connect for some reason with the backend. Any possible reason why is this happening? Is there anything that I should have in the local machine and I am missing? I cannot think of something.

Sergey Karpov

0
Comment actions Permalink

Hi! The remote machine running the script with

pydevd_pycharm.settrace(IP, PORT)

... call should be able to access your host machine where PyCharm is running by the given IP and PORT, which is not always the case.

Could you please double-check the PORT is indeed open on your host machine and host machine's public IP address is used in settrace()? A common mistake is to use the remote machine IP address there instead.

The connection might also be blocked by a firewall.

0
Comment actions Permalink

Hello Pavel Karateev, thank you for your reply.

I have come across these possible reasons and I believe that there is no problem there. I didn't mention in my posts that with the help of Sergey Karpov I had managed to set the Python Debug Server on a Debian 9 machine, about a month ago, so that is the reason why I tagged him in the previous comment.

In the previous setup I used the port 12345, and of course the IP address of the local machine, i.e. the machine where PyCharm runs, but just in case something has changed how can I check that the machine is accessible through this socket? (Although I think that if that was the case, I shouldn't have the same problem in the other machine, I mean that with the Mac OS).

In the machine with the Mac OS I have also checked that the firewall is not activated, so this must be not the case too.

This is the reason I am asking, what can possibly block the frontend from connecting with the backend.

0
Comment actions Permalink

I still have not found why this happens, so here I will describe the procedure I followed in case I am missing something in the whole procedure.

1. I create Run/Debug Configurations specifying

  • IDE host name (local machine public IP address)
  • Port (12345)
  • Path mappings (local project folder = server project folder)
  • install pydevd-pycharm on the environment of the remote machine (current PyCharm version)
  • update the script code with: import pydevd_pychar   pydevd_pycharm.settrace(<Public IP>, port=12345, stdoutToServer=True, stderrToServer=True)

2. Create SFTP connection making Deployment configurations. I have been uploading files to the server successfully.

3. In the next step Deploy files to the remote machine, I deployed the project folder with the pydevd-pycharm.egg file to the server as stated in the insructions ( I also deployed the project without the pydevd-pycharm.egg file).

4. I launched the debug server, and the Debug tool window did display "Waiting for process connection" message. From that I understand that pydevd-pycharm module works well.

5. Finally, I run the script on the server.

note: When I am on the Mac OS machine, I can access the server only through vpn. The IP address that I give in settrace() is the IP that the vpn gives me.

 

p.s.: In the Remote Debugging with PyCharm, article I completely ommit everything that comes before Remote debugging with the Python remote debug server configuration completely, since Creating a deployment configuration for a remote interpreter describes another way for remote debugging. From the article I understand that in order to use the remote debug server, I don't need a remote interpreter for example.

0
Comment actions Permalink

I have the same issue as Kls Thanos and had done the same process. Did you solve it? 

Thanks in advance

0
Comment actions Permalink

Hello Michal Geyer,

I didn't solve the problem because I used the "Remote Interpreter" configuration. This worked fine, so I didn't spent any time further.

You might be ok with this configuration too, and it is straight forward. If you want any help, let me know.

Regards.

0

Please sign in to leave a comment.