Cannot connect to containers based on mcr.microsoft.com/dotnet/core/aspnet:3.0 with VS2019 remote debug - error 0x80004005

Copied from https://github.com/dotnet/dotnet-docker/issues/1530 by @ktos

Steps to reproduce the issue

1. Create a new container where base image is mcr.microsoft.com/dotnet/core/aspnet:3.0 or mcr.microsoft.com/dotnet/core/aspnet:3.1 (or probably older, haven’t tested) on a remote Docker host,
2. Try to connect to process using remote debug in VS2019 16.4.10,
3. Error: Operation not supported. Unknown error: 0x80004005.

Expected behavior

List of processes to be attached to appears.

Actual behavior

An error similar to this:

---------------------------
Microsoft Visual Studio
---------------------------
Unable to connect to 'temperaturektosdev_temperatureservice3_1;ssh=ktos@[redacted]'.  Operation not supported. Unknown error: 0x80004005.
---------------------------
OK   
---------------------------

Additional information (e.g. issue happens only occasionally)

Described the whole problem in Microsoft/DockerTools#222, especially https://github.com/microsoft/DockerTools/issues/222#issuecomment-565748326 - everything is because the lack of ps program in the image. Installing it via apt install procps fixes the issue.

Problem appears only in Buster images, at least not in Alpine (there is ps installed, I confirmed).

Still not sure why it works flawlessly for my LOCAL Docker host (Windows) and not for my REMOTE Docker host (Ubuntu). Maybe there is some difference in getting processes info?

However, I think that ps should be a part of a base image for ASP.NET Core web apps.

Output of docker version

Client:
 Version:           18.09.7
 API version:       1.39
 Go version:        go1.10.1
 Git commit:        2d0083d
 Built:             Fri Aug 16 14:20:06 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.7
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.1
  Git commit:       2d0083d
  Built:            Wed Aug 14 19:41:23 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info

Containers: 11
 Running: 11
 Paused: 0
 Stopped: 0
Images: 21
Server Version: 18.09.7
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version: N/A
init version: v0.18.0 (expected: fec3683b971d9c3ef73f284f176672c44b448662)
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-72-generic
Operating System: Ubuntu 18.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.9GiB
Name: lisa.srv.kilibar.be
ID: PB2S:CT6S:MXWC:RGDU:YPLJ:5AJR:G266:UKX6:2LPL:UZ42:HBU4:7BOW
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Copied from https://github.com/dotnet/dotnet-docker/issues/1530#issuecomment-566730278 by @MichaelSimons

@ktos - in https://github.com/microsoft/DockerTools/issues/222 you said:

Even more strangely, every other container on the same remote host allows me to be debugged, except every ASP.NET Core ones!

Can you share details about these other containers? What technologies are they based on? What base OS are the based on?

Copied from https://github.com/dotnet/dotnet-docker/issues/1530#issuecomment-566771461 by @ktos

@MichaelSimons:

Can you share details about these other containers? What technologies are they based on? What base OS are the based on?

Of course. It seems I overstated “every”. Containers I can successfully connect to show list of processes available to debug are:

• registry:2.7 (https://hub.docker.com/_/registry, https://github.com/docker/distribution-library-image/blob/master/Dockerfile.noarch, based on Alpine),
• couchdb:latest (https://github.com/apache/couchdb-docker/blob/3bcc626d30623789b4750d076f059bcd010c2a04/2.3.1/Dockerfile - based on Debian Stretch, but ps is in that image),
• my own ktos/eleia:latest (https://github.com/ktos/Eleia/blob/master/Dockerfile - based on mcr.microsoft.com/dotnet/core/runtime:3.0-alpine).

Containers throwing error 0x80004005 in VS:

• jc21/registry-ui (based on https://hub.docker.com/r/jc21/node/dockerfile, based probably on https://github.com/nodejs/docker-node/blob/f5875531604b4b3b9fbc36437182781c3655c8ae/10/stretch-slim/Dockerfile - based on Debian Stretch, there is no ps in this image, just checked),
• loicsharma/baget (https://github.com/loic-sharma/BaGet/blob/master/Dockerfile, based on microsoft/dotnet:2.2-aspnetcore-runtime),
• my own based on microsoft/aspnetcore:2.0,
• my own based on mcr.microsoft.com/dotnet/core/aspnet:3.0

Copied from https://github.com/dotnet/dotnet-docker/issues/1530#issuecomment-566775007 by @ktos

And I just checked - couchdb:latest is Debian Stretch based, however it installs procps because couchdb requires it: https://github.com/apache/couchdb-pkg/blob/master/debian/control#L38

Copied from https://github.com/dotnet/dotnet-docker/issues/1530#issuecomment-567219203 by MichaelSimons

@dbreshears - Is this something that falls under your area of ownership? If not do you know who does?

The UX doesn’t seem ideal here.

1. I would expect a better error message indicating ps is required when it is not found.
2. Given ps is not included in the Debian base OS image, what is your recommendation here? Is it possible for the tooling to dynamically install any dependencies it requires?

Copied from https://github.com/dotnet/dotnet-docker/issues/1530#issuecomment-567226668 by @dbreshears

@gregg-miskelly, is this something you can help with?

Copied from https://github.com/dotnet/dotnet-docker/issues/1530#issuecomment-567249893 by @gregg-miskelly

@dbreshears can you transfer this issue to Microsoft/MIEngine? CC @pieandcakes

[pieandcakes]

We can take another look and see if we can switch what is being generated.

[MichaelSimons]

From a Linux container perspective I think the usability of zips and requiring unzip to be installed within the container is a limiting factor. tar has been supported in Windows for sometime now. Can you make use of it within your builds to produce tarballs?