Usage of --id-label yields hanging process

[NicoDietrich]

Version of devcontainer-cli: 0.52.1 OS: Ubuntu 20.04 Shell: bash/zsh

Issue: Using --id-label to identify the container, and be able to spawn multiple devcontainers based on the same devcontainer.json, yields a hanging process after starting the container with devcontainer up.

Expected behavior: The process should not hang, as is the case if --id-label is not used.

Reproduce:

• Clone this repository: git clone https://github.com/devcontainers/cli.git
• Start devcontainer with id-label: cd cli && devcontainer up --workspace-folder . --id-label name=hello

Simply using devcontainer up --workspace-folder . works as expected.

[samruddhikhandale]

Hi 👋

I wonder if you are running into https://github.com/devcontainers/cli/issues/652 ? As the container name is not making use of id-label, it's not able to distinguish two running containers.

[NicoDietrich]

Hey (: The issue i am describing occurs also when dealing with one container. The container is successfully created, but the process hangs. When I "STRG-C" the process, the running container remains and can be used. I don't think this behavior is intended.

On a side note:, I tried to work around the usage of --id-label by changing the --name flag in the devcontainer.json "runArgs" but then the creation of multiple containers does not seem possible. It seems to me that devcontainer-cli distinguishes between two setups via the id-label and not the name of the container.

[ruffsl]

The issue i am describing occurs also when dealing with one container.

I'm encountering the same issue as well with devcontainer --version 0.65.0. When using --id-label with devcontainer up, it just never seem to execute the lifecycle scripts. E.g. as expected:

$ devcontainer up --workspace-folder .
...
Container started
Running the onCreateCommand from devcontainer.json...

Running the updateContentCommand from devcontainer.json...

[ruffsl]

Just found if I Ctrl+C the first run of devcontainer up, then re-run it again with the container up, the life cycle script run:

$ devcontainer up --workspace-folder . --id-label name=hello
...
Container started
^C⏎ 

$ docker ps
CONTAINER ID   IMAGE                                                                                     COMMAND                  CREATED         STATUS          PORTS     NAMES
81739a10575e   vsc-hello-fe3143fff7ac948ee2ec5ff9f12710dd581f7d2ff15adc4692f71484970d9a34-features-uid   "/bin/sh -c 'echo Co…"   4 minutes ago   Up 4 minutes              quizzical_bhabha

$ devcontainer up --workspace-folder . --id-label name=hello
...
Container started
Running the onCreateCommand from devcontainer.json...

Running the updateContentCommand from devcontainer.json...

So it seem to be something stateful, or perhaps a deadlock that is bypassed with rexecuted?

[ruffsl]

Hmm, I think this may have something to do with the label key name colliding with something internally.

As when using a different key, it seems to work as expected. E.g:

$ docker rm -f $(docker ps -aq)
$ devcontainer up --workspace-folder . --id-label foo=hello
...
Container started
Running the onCreateCommand from devcontainer.json...

Running the updateContentCommand from devcontainer.json...
...
$ devcontainer exec --id-label foo=hello bash
ubuntu@9713b2dda63b:~$