Cannot connect to debug port on Windows (WSL2) #12292
Comments
|
Are you able to connect the ones on |
|
yes I am able to access HTTP port 8080, it can render the application page correctly. |
|
Can you verify that port 8000 is working inside the container? My suspicion is more with Tomcat than with Podman given what you've described. |
|
I could verify from Tomcat log that it started service for port 8000 as well as port 8080 from catalina log. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@voquangphu By any chance have you updated to the latest Podman and latest podman machine (OS) |
|
From the Windows host, can you check if http://[::1]:8000 works? I suspect it will work and only http://127.0.0.1:8000 fails, which is by default what localhost:8000 is. |
|
I asked the same question in WSL 2 and this solution works, I'll try to see if http://[::1]:8000 also works when I have sometime. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Is this still an open issue, or have you found a solution @voquangphu |
Yeah, that works. I used it for a sql server podman like this: |
|
This is not a Podman problem but a WSL2 problem: WSL2 treats a socket listening as "*:8080" (= accepting any IPv4 or IPv6 connection) on Linux side in an unexpected way by only binding to an IPv6 socket on the Windows side (see also microsoft/WSL#4851).
The workaround is to let Podman explicitly open a listening IPv4 socket by using a port mapping like Example (executed in Powershell on Windows, using a Debian sid based WSL2 distro and Podman from its packages): As you can see, Podman's If you'd do the same with Docker, you'd see that with @rhatdan is this difference with Docker by design, or unintentional? |
|
This definitely sounds like a bug, though I'm honestly quite tempted to call it a bug in WSL because this breaks decades of Unix conventions. Still, if there's a workaround to convince WSL to bind only to v4 addresses in these cases, I'm not opposed to adding it, it won't hurt and it seems like it could be a while before the WSL problem is resolved. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
I'm encountering this problem as well (Win 11 21h2) |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Since this is described as a WSL2 bug, I don't see Podman doing much to fix it. So I am closing. @n1hility WDYT? |
|
@rhatdan hmm since this works for rootfull and not rootless I wonder if we should change rootlessport to have a setting we can trigger for WSL configs that would either force wildcard to tcp4 (WSL doesn't support fully ipv6 anyway) or setup a tcp4 and tcp6 listener vs the the dual-stack sock. It's technically something we shouldn't have to do, but might remove a usability barrier. I'll ponder some more on this. |
|
+1 @n1hility The thing is that Docker works that way, and therefore doesn't trigger the problem. For WSL users trying to migrate to Podman this comes as a surprise when they see something "that works with Docker now doesn't work with Podman", from their point of view. |
|
/reopen |
|
@n1hility: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Hi everyone, the fix for this will be included in the 4.1 release, and won't require any special properties. You will need to reinit your machine after installing 4.1 [when released] to get the update (podman machine rm; podman machine init.) In the meantime you can use the 127.0.01 workaround above, or you can switch to rootfull. Thank you @davdr for identifying and calling out the root cause. |
|
@n1hility does it require podman machine or any other conditions to work? I have Debian Sid with Podman upgraded to 4.1 (4.1.0+ds2-2 via https://packages.debian.org/experimental/podman), and behavour doesn't seem to have changed (did a podman system reset to get the new network stack): rootlessport is still opening a dual-stack socket. |
@davdr Yes it does rely on machine integration, but you can trigger it manually by creating “ /etc/containers/podman-machine” with the content of “wsl” (quotes excluded) |
|
(Rootlessport looks for that file to decide how to bind) |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I have been trying to migrate all Docker recipes to Podman for both Mac and Windows.
On Windows running Debian (WSL 2) I am able to install, build and run Podman container successfully, running Tomcat 7 service and access the service from Windows host (via localhost:8080).
However, I am not able to connect to debug port 8000 inside container for some reasons. (I'm using IntelliJ to debug)
Steps to reproduce the issue:
Install Java 1.8 and Tomcat 7
Setup Catalina option in /usr/share/tomcat/conf/tomcat.conf with the below option
service tomcat startAttach to remote JVMto localhost:8000Describe the results you received:
Error running 'remote-debug': Unable to open debugger port (localhost:8000): java.net.ConnectException "Connection refused: connect"
Describe the results you expected:
Debugger connects to Tomcat instance inside Podman container running on WSL 2.
Additional information you deem important (e.g. issue happens only occasionally):
Some additional things I want to add:
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
Debian on WSL 2 (Windows)
The text was updated successfully, but these errors were encountered: