Feature entrypoint does not fire when Docker Compose definition is used

[jrussellsmyth]

• VSCode Version: 1.62.3
• Local OS Version: MacOS 10.14.6 Docker Desktop Version 3.6.0 (3.6.0.5487)
• Reproduces in: Remote - Containers
• Name of Dev Container Definition with Issue: desktop-light feature

Steps to Reproduce:

1. clone this repo https://github.com/jrussellsmyth/feature-desktop-compose-dosnt-run
2. open in VSCode
3. reopen in container
4. attempt to connect to VNC on http://localhost:6080/

• will fail

5. can also forward port 6080 and try http://localhost:6080/

• will still fail

[Chuxel]

This is likely an issue with the extension rather than the script / feature. It also seems to repro in the current VS Code - Insiders

@chrmarti , @joshspicer - It looks like the entrypoint configured in features.json is not firing properly in this Docker Compose case. If I manually run /usr/local/share/desktop-init.sh, everything is working with the feature as expected.

In addition to the desktop, if I tweak the devcontainer.json to use docker-in-docker, is also set up but similarly does not start the docker engine.

[Chuxel]

I also if it is a bug and not something I'm missing, we should probably look at getting this one in for 1.63 since as feature use starts to grow.

[joshspicer]

Is this in the latest remote containers v0.208.0?

Looks like I can repro in codespace too (both desktop and dind).

[chrmarti]

Does adding "overrideCommand": true to the devcontainer.json make it work?

[Chuxel]

@chrmarti Yep! That's does appear to be the issue since its false by default for Docker Compose.

[joshspicer]

@chrmarti - for reference, how is the entrypoint determined if multiple features are used, each with a custom entrypoint?

If a user is utilizing a feature with a custom entrypoint (like dind here: https://github.com/microsoft/vscode-dev-containers/blob/main/script-library/container-features/src/features.json#L22), should we automatically be setting overrideCommand?

[jrussellsmyth]

verified for me "overrideCommand": true does make the feature work

[Chuxel]

Yeah, I would not expect to have to set this manually.

[chrmarti]

The default does not override because we didn't have that for Docker Compose before and changing it would break existing setups.

[Chuxel]

@chrmarti This won't work because there is no way for the user to know that is the case - so sadly it looks broken as seen here. In terms of existing setups, they made a change, so when this happens it would be clear that the feature is what affected the outcome... and our own bases are setup to work this way.

The problem is that, if you to do not alter the ENTRYPOINT, nothing works - so not making that switch really adds little value. The script is essentially /dev/null. If a feature with an entrypoint in feature.json is selected, the entry point is needed since there's no systemd in most images, we end up approximating it with entrypoints.

That said, we don't need to not remove the existing entrypoint anyway. We can call the existing entrypoint after all of ours (it's available in the resulting image metadata). This is why I've got these entry points setup to enable chaining. e.g.

ENTRYPOINT: [ "/usr/local/share/docker-init.sh", "/usr/local/share/dekstop-init.sh", "existing-entrypoint-goes-here" ]

At this point, the command can be "as-is", its only the entrypoint that is updated. It's a new behavior yes, but only when you use a feature that has an entrypoint set.

Perhaps though there are two bugs if we are also stepping on the existing enterypoint?

[chrmarti]

One issue with the chaining is that we would require feature authors to enable that too. I have now come up with an approach that sets the user's entrypoint and command as the new command, so we can use the entrypoint to run the feature entrypoints, then (if overrideCommand is not true) run the user's entrypoint and command and finally go into a sleep loop.

We can always do this (also with no feature entrypoints) with the additional benefit of when the user's entrypoint exits, we keep the dev container running with the sleep loop. This might allow us to remove the requirement for the user to have a sleep loop (or sleep infinity) in the docker-compose.yml.

[chrmarti]

Doing the same for single containers. The default there is to override the entrypoint and command by default, but the same issue would occur when you add "overrideCommand": false to the devcontainer.json.