Pycharm Debugger hangs when using with docker-compose

Completed

I'm running Pycharm 2017.1.2 on Linux and have a remote interpreter configured using docker-compose. It works fine when I run a standard Django server or run tests normally. However, when I run the debugger, it connects to the pydev debugger and then hangs without an error message. (see my screenshot)

It's strange because this used to work fine. I think it might have stopped working since updating the latest minor PyCharm release?

 

7 comments

Quick question: do you have any form of auto-reloading enabled in your Django setup?

Reason I ask is I've managed to get my debugger running by turning auto-reloading off. Which is definitely not ideal in a development environment, but at least I have an option available to debug problematic code now.

Does it work for you though?

4

I have exactly the same issue!

In my case, I'm using python Bottle (micro framework), running inside docker containers, and am also using docker-compose. Using PyCharm 2017.1.2,  I set up the remote interpreter (using the Docker Compose option), and it appears to be working correctly as I can successfully run the launch script. Everything then works as expected.

However, when attempting to execute the debugger, I have exactly the same symptoms as Patrick Craston. Some observations that I noted (whether relevant or not):

  1.  my containers are successfully started, as executing `docker ps` in the terminal shows the containers as being started, and running `docker inspect <container>` outputs the expected result;
  2. attempting to ping the hanging container using both its name and IP address (as obtained from `docker inspect`) returns no response - its as if networking within the container has failed or not started;
  3. debugging the container appears to work before it hangs... if I set a breakpoint at the very start of the script that launches the web server in the container, then PyCharm does in fact hit the breakpoint, and I can trace execution all the way until the web server is launched. After that, it appears to hang, with the previous mentioned symptoms.

Unfortunately, I can't comment on whether it was working in previous versions. Either way, it would be super helpful to get it resolved.

Edit: Or I'd be happy with a workaround, even a hacky one at that...

3

Yes indeed! Django development server does auto-reloading by default. If I turn that off by adding the --noreload flag, the PyCharm debugger works fine.

Thanks for the hint and the workaround, although I agree that it would be good to get it fixed properly! Do you want to add this information to the bug on youtrack?

2

Are you able to run tests using the debugger? Because that works fine for me, it is only when I tried to run the Django server that the debugger hangs.

0

I haven't tried running tests yet - I was working against a Hello World type of application (single wgsi server application with a single endpoint returning a single line of text),  just to investigate the problem. However, I seem to think that they would work... as I mentioned in my previous post, debugging all the way up to the start of the application server works correctly, and only hangs on that specific call... in fact, debugging a non app server python script works perfectly fine on my end.

As far as I can tell at the moment, all fingers are pointing to it having something to do with the WGSI server being started... everything works up until execution reaches the point of starting the server... then it hangs.

As a side note, I've removed network and port configurations from my docker-compose YAML files, to no avail... so I'm pretty sure its something specific to the way PyCharm is attempting to start the app server in the container.

0

On a related note, I did file a bug for this and included a link to this post.

Bug is at: https://youtrack.jetbrains.com/issue/PY-24191 

0

Happy to hear that it is working for you as well. I did include my findings as a comment to the bug report, but I can update it with your feedback as well... hopefully it gets a look at by the devs at some point soon. 

0

Please sign in to leave a comment.