cli icon indicating copy to clipboard operation
cli copied to clipboard

devcontainer always started with `"Init": true` no matter the settings

Open jonnylangefeld opened this issue 2 years ago • 5 comments

I'm trying to set init to false for a devcontainer where I need to control PID 1.

However, no matter how I set init to false, the resulting dev container has init always set to true:

╰─ docker inspect life_life_1 | grep Init
            "Init": true

This also shows in the logs:

[2024-01-19T17:33:17.093Z] Docker Compose override file for creating container:
version: "3.8"

services:
  'life':
    entrypoint: ["/bin/sh", "-c", "echo Container started\n
trap \"exit 0\" 15\n
\n
exec \"$$@\"\n
while sleep 1 & wait $$!; do :; done", "-"]
    command: ["/sbin/init"]
    init: true
    privileged: true
    cap_add:
      - SYS_PTRACE
      - SYS_ADMIN
    security_opt:
      - seccomp=unconfined
    labels:
      - 'devcontainer.local_folder=/home/workspaces/ife'
      - 'devcontainer.config_file=/home/workspaces/life/.devcontainer/devcontainer.json'
    volumes:
      - vscode:/vscode
volumes:
  
  vscode:
    external: true

Here is what I've tried:

  1. Setting it in devcontainer.json. This seems to be the most obvious one. Although the default should actually be false. This doesn't work, the resulting container will still have "Init": true.
{
    "name": "life",
    "init": false,
    ...
}
  1. Setting it in docker-compose.yml. Of course I also set it in my docker-compose.yml, but that just got overridden by devcontainer cli.
  2. Setting it in Dockerfile. I've also set it via
LABEL devcontainer.metadata='[{ \
  "init": false \
}]'

as described in the docs, but still in the resulting container it's true.

I've set all these at once to false and still the resulting container has it set to true.

The line of code in question is this one: https://github.com/devcontainers/cli/blob/47354089b2eacf89b713dde767ca5536c2d6fa60/src/spec-node/imageMetadata.ts#L172 But where could it possibly get a true from?

jonnylangefeld avatar Jan 19 '24 17:01 jonnylangefeld

I am one step further and know now that that the true value comes from here since I'm using the go feature: https://github.com/devcontainers/features/blob/65fb90b7fc8634986ab5644d00d66b983e9a50df/src/go/devcontainer-feature.json#L25

So maybe the two are incompatible. Is there any way I can use the go feature without the init flag set to true?

jonnylangefeld avatar Jan 19 '24 18:01 jonnylangefeld

Your analysis is correct, the go feature appears to require init and there is currently no way to override this.

@samruddhikhandale Do you remember why the go feature uses "init": true?

chrmarti avatar Jan 24 '24 09:01 chrmarti

We seem to have added it everywhere at one point, but only two (go and desktop-lite) are left today. (https://github.com/microsoft/vscode-dev-containers/commit/bee0f0d7d1f86e9cb394e4e497ce9310915fa3d9#diff-f63c12035617f7f18f92b8633834f62142a15ebf2e143948b37a6e90228a7c5f)

chrmarti avatar Jan 24 '24 09:01 chrmarti

@samruddhikhandale Do you remember why the go feature uses "init": true?

Yep, that was historically added when we had Feature as scripts in https://github.com/microsoft/vscode-dev-containers

While migrating over to devcontainers/features, we only added init to go and desktop-lite Features. See https://github.com/devcontainers/features/pull/1

I am not super clear on why we added init to the Go Feature, but probably @joshspicer might know more.

samruddhikhandale avatar Jan 24 '24 19:01 samruddhikhandale

I believe the intital change was made in hopes to improve performance/reliability, for a reason simliar to https://stackoverflow.com/a/44689700

joshspicer avatar Jan 25 '24 01:01 joshspicer