podman: Cannot connect to debug port on Windows (WSL2)

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:

  1. Run a CentOS 6 base instance with port mapping 8080 and 8000
podman run -td --name centos -p 8080:8080 -p 8000:8000 centos:6.10 bash -l
  1. Install Java 1.8 and Tomcat 7

  2. Setup Catalina option in /usr/share/tomcat/conf/tomcat.conf with the below option

CATALINA_OPTS="-Dlog.host=`hostname -s` -Xms256m -Xmx256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseG1GC -Djava.security.egd=file:/dev/./urandom -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"
  1. Start tomcat service using service tomcat start
  2. On Windows host, run IntelliJ, setup remote JVM debug to Attach to remote JVM to localhost:8000
  3. Run the above debug configuration

Describe 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:

  • I use the same recipe for Podman on Mac running Podman machine VM, and IntelliJ is able to connect to debug port localhost:8000
  • I also tested with Windows Docker Desktop running WSL 2 backend and IntelliJ is also able to connect to debug port localhost:8000
  • I checked if port 8000 is accessible from Windows host using netstat, and both port 8080 (obviously) and port 8000 were listening.
PS C:\Users\christopher.vo> netstat -a | findstr :8000                                                                    TCP    [::1]:8000             P50442:0               LISTENING
PS C:\Users\christopher.vo> netstat -a | findstr :8080                                                                    TCP    [::1]:8080             P50442:0               LISTENING

Output of podman version:

Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.9
Built:        Thu Jan  1 09:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.6
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 4
  distribution:
    distribution: debian
    version: "11"
  eventLogger: journald
  hostname: P50442
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.16.3-microsoft-standard-WSL2
  linkmode: dynamic
  memFree: 4746706944
  memTotal: 13265854464
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /tmp/podman-run-1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    selinuxEnabled: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.4.0
  swapFree: 4294967296
  swapTotal: 4294967296
  uptime: 5h 11m 13.78s (Approximately 0.21 days)
registries: {}
store:
  configFile: /home/christopher/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.10.3
        fuse-overlayfs: version 1.4
        FUSE library version 3.10.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/christopher/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 27
  runRoot: /tmp/podman-run-1000/containers
  volumePath: /home/christopher/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 0
  BuiltTime: Thu Jan  1 09:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.9
  OsArch: linux/amd64
  Version: 3.0.1

Package info (e.g. output of rpm -q podman or apt list podman):

Listing... Done
podman/stable,now 3.0.1+dfsg1-3+b2 amd64 [installed]

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)

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 26 (11 by maintainers)

Most upvoted comments

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.

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.

@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)

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. https://github.com/microsoft/WSL/issues/7732