microsoft / ptvsd

Python debugger package for use with Visual Studio and Visual Studio Code.
Other
548 stars 68 forks source link

Connection Refused 111, Internet Access and Proxies #2098

Closed grepusername closed 4 years ago

grepusername commented 4 years ago

Environment data

Actual behavior

When attempting to debug any code the connection to the debugger is refused with the following message:

/home/grep_username/venv/tufin_workflows/bin/python /home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/ptvsd_launcher.py --default --client --host localhost --port 38057 /home/grep_username/code/toys/test.py 
E00000.013: Exception escaped from start_client

            Traceback (most recent call last):
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/log.py", line 110, in g
                return f(*args, **kwargs)
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/pydevd_hooks.py", line 74, in start_client
                sock, start_session = daemon.start_client((host, port))
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/daemon.py", line 217, in start_client
                connect(client, addr)
            File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/socket.py", line 197, in connect
                sock.connect(addr)
            ConnectionRefusedError: [Errno 111] Connection refused

Traceback (most recent call last):
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/ptvsd_launcher.py", line 48, in <module>
    main(ptvsdArgs)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/__main__.py", line 432, in main
    run()
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/__main__.py", line 300, in run_file
    setup_connection()
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/__main__.py", line 291, in setup_connection
    daemon = ptvsd._remote.attach(addr)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_remote.py", line 95, in attach
    patch_multiprocessing=ptvsd.options.multiprocess)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace
    wait_for_ready_to_run,
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace
    debugger.connect(host, port)  # Note: connect can raise error.
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect
    s = start_client(host, port)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/pydevd_hooks.py", line 136, in _start_client
    return start_client(daemon, h, p)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/log.py", line 110, in g
    return f(*args, **kwargs)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/pydevd_hooks.py", line 74, in start_client
    sock, start_session = daemon.start_client((host, port))
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/daemon.py", line 217, in start_client
    connect(client, addr)
File "/home/grep_username/.vscode-server-insiders/extensions/ms-python.python-2020.2.64397/pythonFiles/lib/python/old_ptvsd/ptvsd/socket.py", line 197, in connect
    sock.connect(addr)
ConnectionRefusedError: [Errno 111] Connection refused

Expected behavior

Successful debugging behaviour

Steps to reproduce:

  1. Open File (in this instance test.py contains only 'print("hello world")')
  2. Select Debugging profile such as the default: { "name": "Python: Current File", "type": "python", "request": "launch", "program": "${file}", "console": "integratedTerminal" }
  3. Failure occurs.

There are two factors that may be relevant here:

  1. A recent change to corporate proxies means that most internet requests return an SSO page rather than allowing access (as it was before) or returning an error or timeout (as we would prefer).
  2. a sudo apt update && sudo apt upgrade was performed within the last week

On a similar server (though running RHEL 7.7) debugging continues to connect - however, it is both able to connect to the internet/doesn't have a pernicious proxy configuration and hasn't been upgraded in months.

int19h commented 4 years ago

The connection that it's trying to make should be to 127.0.0.1 - is there anything in your firewall settings that might prevent that?

grepusername commented 4 years ago

Hey int19h,

There is not:

 ~/sudo ufw status
 Status: inactive

There is nothing much listening at the moment but connecting to a few thing that are listening on relatively arbitrarily ports works fine, e.g.:

~/telnet 127.0.0.1 55443
Trying 127.0.0.1... 
Connected to localhost.
Escape character is '^]'.
int19h commented 4 years ago

Hm... I don't know if that would help, but connection handling is considerably different in the new version of the debugger - can you try the current pre-release, and see if that makes any difference?

grepusername commented 4 years ago

Further testing has revealed that it isn't the proxy access that is the issue but the presence of docker or the docker host address. Further testing required on my end at least.