V2 can not delete Container over ssh if there is more than one

[Herr-Sepp]

Description

Try to "down" a compose over ssh will fail with V2 that worked in V1.
Can only recreated with -HOST and it need to be two or more services inside the compose (one services works)

Steps to reproduce the issue:

1. Compose:

version: '3.8'
services:

  busybox1:
    image: busybox
    command: "sleep 1d"
    
  busybox2:
    image: busybox
    command: "sleep 1d"

.\docker-compose-v2.exe -H ssh://USER@docker-vm up -d && .\docker-compose-v2.exe -H ssh://USER@docker-vm down

Describe the results you received:

[+] Running 2/2
 - Container composev2-busybox2-1  Started                                                                            1.2s
 - Container composev2-busybox1-1  Started                                                                            2.8s
[+] Running 1/2
 - Container composev2-busybox2-1  Removed                                                                           10.5s
 - Container composev2-busybox1-1  Error while Removing                                                              11.8s
error during connect: Delete "http://docker/v1.41/containers/9ec831308cba7cd8c68a698c7e1db9985974033918f58def885d18ba9b9059e4?force=1": command [ssh -l USER -- docker-vm docker system dial-stdio] has exited with exit status 1, please make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=

The second Container is still there and not removed:

docker -H ssh://USER@docker-vm ps -a

CONTAINER ID   IMAGE     COMMAND      CREATED          STATUS                       PORTS     NAMES
5e4141ce6748   busybox   "sleep 1d"   20 seconds ago   Exited (137) 3 seconds ago             composev2-busybox2-1

Describe the results you expected:

Output from ComposeV1:

Recreating composev2-busybox1-1 ... done
Creating composev2_busybox2_1   ... done
Stopping composev2_busybox1_1 ... done
Stopping composev2_busybox2_1 ... done
Removing composev2_busybox1_1 ... done
Removing composev2_busybox2_1 ... done
Removing network composev2_default

All Container are successfully removed

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version v2.2.3

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.3)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 140
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-96-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 6
 Total Memory: 7.719GiB
 Name: 
 ID: Q5VN:WVLA:LJRP:SMDW:XJUB:OG23:NUXF:THXI:G3OH:CJRC:CCJ7:XRG3
 Docker Root Dir: /var/lib/docker
 Debug Mode: 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

Additional environment details:

[alecgarza96]

/assign

[Herr-Sepp]

I tried it again with the current version and it still occurs with 2.3.3.
Same behavior as described above

Workaround is not to use the -Host-option but to pass the compose command with SSH
Before that the Compose file must be transferred to the VM and Compose must be present there.

[Herr-Sepp]

i can not recreate the bug with 2.10.1, so it has been fixed in a release between 2.3.3 and 2.10.1

[Herr-Sepp]

Sorry i was wrong. I got the some error with 2.10.1

I think it has more todo with my SSH-Client / Server configuration then compose so i will leave the issue closed.
Switching to a tcp connection has fixed it for me.
-H tcp:// ...