Fail to debug Python project on Linux

[v-ruizh]

OS: Linux
Build Version: 20200304.7

Repro Steps:

1. Open a Python project(General/Django/Flask) in VS Code.
2. F1->Docker: Add Docker Files to Workspace->Python->include docker compose files.
3. F5.

Expect:
Debug Python project successfully without any error.

Actual:
Fail to debug Python project.

More Info:
This issue does not reproduce on Windows and Mac.

[bwateratmsft]

@v-ruizh were any other containers running at the time that could have been holding port 5678?

[v-ruizh]

@bwateratmsft I remove all running container and then debug again. There is no error in logs. But another error dialog pops up. (This issue also reproduces on Windows and Mac, but it's unstable)

[haniamr]

@v-ruizh do you have a repro environment that I can look at?
I couldn't repro this on an Ubuntu machine, what Linux distro are you using?

A couple of more questions:

• Is there anything printed in the debug console?
• While the container is running, can you do "docker logs {containerId}" and share if there's any output?
• While the container is running, do the following and share the output:
  • "docker exec {containerId} cat /dbglogs/ptvsd-1.log"

Thanks!

[karolz-ms]

Just tried on Ubuntu 18.04 machine via Remote-SSH and it works... 😕

BTW It is pretty cool that the server runs remotely, but my browser still can reach it via a localhost port

[bwateratmsft]

@karolz-ms That had us confused for a bit until we realized that it's some VSCode magic, since we use their openExternal API. They're basically making a "proxy" locally.

[notpushkin]

Sorry for hijacking this issue, but how can one get the nightly builds? Or the only way is to build it by hand?
My bad, just noticed the pinned thread #1408

[haniamr]

To provide more context, this happens as the VM is not directly on the physical machine but in a nested VM, which caused the weird side effect that files created in the container in a volume were not accessible in the host.

Since @karolz-ms and @v-ruizh confirmed this is not reproducing given the VM is directly on the physical machine, I'll close the issue for now.