Ptvs: using ptvsd remotely debugging from Django's development web server binding issue

[markrowsoft]

I apologize if this is simply a user configuration issue but it appears that within one python process we are limited to binding to one IP address. So when trying to run "python manage.py runserver" after adding pdvsd lines results in an error. Is there a way around this? Threading? SocketServer module??

Traceback (most recent call last):
File "manage.py", line 4, in
ptvsd.enable_attach(secret = 'dev', address = ('0.0.0.0', 1977))
File "/usr/lib/python2.7/site-packages/ptvsd/attach_server.py", line 162, in enable_attach
server.bind(address)
File "/usr/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 98] Address already in use

No other processes are running on this port.

[int19h]

It's limited to it in a sense that so long as it's the same code that runs, it's up to you to ensure that on the second concurrent run it has to use a different endpoint. For example, you can pick a port randomly, print it out, and then pass that random port to enable_attach; then every process can be attached to separately (so long as you have a way to find out which port it picked).

A better way to fix this would be to allow ptvsd to attach to VS, instead of the other way around. Then VS can keep a single port open, and several processes can use ptvsd to attach to that VS session for debugging.

[zooba]

I don't think this is a concurrent run, it's that Django itself is also trying to listen on 0.0.0.0 and this is apparently not working. That doesn't seem to make sense though - I'm sure we've done this before.

Does it make a difference if you also call ptvsd.wait_for_attach immediately after enabling? Maybe we can't listen on the same address multiple times, but once the connection is established it is fine.

[int19h]

Listening the same IP 0.0.0.0 shouldn't be a problem if it's on a different port. So the only way this should be hit is if Django somehow causes this code to be run more than once (or if that port number is actually used for something else).

[markrowsoft]

So .. from the error I posted above ... it is true.. address 0.0.0.0 is in use but like you said, that shouldn't matter so long as the port isn't being used. I checked on the server if the port was in use with a quick netstat -atun | grep 1977 resulting in nothing ... I ran the django development web server on 8080.

Theoretically it should have worked.

[zooba]

Do you need to use port 1977, or can you use a different one? Does it work on any other port?

[markrowsoft]

I can use any port necessary, out of curiosity I tried a higher port 46000 with the same result. Is there a better well-known port I should be using?

[zooba]

Not that I'm aware of. This is very strange, but I suspect it's something platform-specific. We'll need to spend some more time looking into it, or see if anyone else has any ideas.

[markrowsoft]

Update: I did notice that the locale windows version of Django (1.5.12) was newer than the version on my remote RHEL 6 machine (1.4.9) to which I was trying to remotely debug. Though the actual code I was debugging was identical and runs fine using the older version of Django. I will re-post when I try with identical versions of Django.

[tinganho]

I'm getting the same problem with Django 1.8.14.

[zeus]

Same bug on CentOS (RHEL) 7 and Django 1.8.
Works fine on windows machine, but fail in docker container with CentOS7.

[ppbrasil]

For some reason I didn't get yet, Django was calling the ptvsd.enable_attach("secret", address = ('0.0.0.0', 3000))twice during it's start up.
I solve the issue by closing the socket before ptvsd tryed to attach it

import socket
import ptvsd

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.close()
ptvsd.enable_attach("secret", address = ('0.0.0.0', 3000))

[markrowsoft]

Nice! I will have to try this out.

On Wed, Feb 15, 2017 at 6:16 PM ppbrasil [e-mail] wrote:

For some reason I didn't get yet, Django was calling the ptvsd.enable_attach("secret",
address = ('0.0.0.0', 3000))twice during it's start up.
I solve the issue by closing the socket before ptvsd tryed to attach it

`import socket
import ptvsd

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.close()
ptvsd.enable_attach("secret", address = ('0.0.0.0', 3000))
`

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/PTVS/issues/1057#issuecomment-280209317,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwTH3hTBsPdHb-CyaQz2cjcKWj4giAOks5rc7GXgaJpZM4HFTn_
.

>

Mark
https://www.linkedin.com/in/markengstrom

[ppbrasil]

I don't know why, but today it decided not to work.
So I took another approach and could connect using

try:
ptvsd.enable_attach("secret", address = ('0.0.0.0', 3000))
except:
pass

The drawback is that now I have two different processes listening to the same port.

python 1 root 4u IPv4 281893 0t0 TCP *:3000 (LISTEN)
python 12 root 4u IPv4 281893 0t0 TCP *:3000 (LISTEN)

[weinickli]

I'm getting the same problem with Django 1.8.18. to.

[chyld]

Also getting the same error on an Linux Docker container running Flask 0.12.

[zooba]

Not sure about Flask, but I noticed the other day that Django seems to start two processes when you run it now (as of a recent update? I'm not sure). That is likely to cause trouble when we try to listen on the same port twice - likely an exception.

As an idea to investigate - if Django has some variable that shows it is in the second process (which I assume is the one that does the actual work), that is the one we want to enable attaching in.

[sandhje]

If anyone encounters this problem like me: A workaround is adding the --noreload flag to manage.py runserver (for Django). Having to re-run the runserver command everytime the code changes sucks, but debugging with print statements is even worse! Hope it helps.

Credit: http://ramkulkarni.com/blog/debugging-django-project-in-docker/

[zooba]

Hopefully the workaround is fine for now. We are looking at long-term debugger improvements that may help here, but nothing specific for this issue.

[quinox]

To use the auto reloading functionality you can make VSCode only attach in the main process. Based on Django's utils/autoreload.py and Django-Extensions' management/commands/runserver_plus.py:

if os.environ.get('RUN_MAIN') or os.environ.get('WERKZEUG_RUN_MAIN'):
    ptvsd.enable_attach(address=('0.0.0.0', 7913), redirect_output=True)

[joke2k]

To use the auto reloading functionality you can make VSCode only attach in the main process. Based on Django's utils/autoreload.py and Django-Extensions' management/commands/runserver_plus.py:

if os.environ.get('RUN_MAIN') or os.environ.get('WERKZEUG_RUN_MAIN'):
    ptvsd.enable_attach(address=('0.0.0.0', 7913), redirect_output=True)

where I've to add these lines? :D

[quinox]

where I've to add these lines? :D

Some place that gets loaded on startup; I put them in settings.py, but fe. urls.py should also work.