go feature: "init:true" prevents any further use cases that require "init:false", such as running systemd as PID1

Aberta
#1,765 0 comentários 0 reações 1 responsável Ver no GitHub

@v-Kaniska244 já está trabalhando nisso.

Desde 5/11/2026.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
55/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
docker, go, shell

Direção de pesquisa

Start by reading the Go feature's devcontainer-feature.json and trace how its init setting is combined with devcontainer.json settings. Check whether the feature needs init: true for process cleanup, then compare the behavior with the use case in the issue. Done means either users can disable init for the Go feature or its reason is documented.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

The go feature's devcontainer-feature.json sets "init": true. Unfortunately, I couldn't find any documentation, commit message or issue that explains the reason(ing) behind this forced setting. Because of the way the CLI merges init, no devcontainer.json can turn it back off. Any devcontainer that needs its own PID1, such as systemd, can't use the go feature.

Use Case

Running systemd as PID1 in a devcontainer to test against certain systemd behavior tied to PID1 as opposed to running systemd as non-PID1. For example:

{
  "build": { "dockerfile": "Dockerfile" }, // ENTRYPOINT ["/usr/lib/systemd/systemd"]
  "overrideCommand": false,
  "init": false,
  "privileged": true,
  "features": {
    "ghcr.io/devcontainers/features/go:1": {}
  }
}

Without the go feature this works: the CLI's /bin/sh -c '… exec "$@"' wrapper execs the image's ENTRYPOINT, so systemd becomes PID1.

But when adding the go feature, the CLI combines init from devcontainer.json and all features so that any true wins. The container is then started with --init, tini becomes PID1, and systemd refuses to start because it isn't PID1. The explicit "init": false in devcontainer.json is ignored.

  • The Go definition this feature replaced (microsoft/vscode-dev-containers, containers/go) used only --cap-add=SYS_PTRACE --security-opt seccomp=unconfined, without --init.
  • Might init: true be set so that leftover processes get cleaned up (for example after Delve kills a debugged program, or child processes from go test and gopls)?
  • Feature metadata can't depend on options, so users have no way to opt out today.

Would it be possible to remove this setting? If not, could you please document the reason why it is needed with this feature?

Linguagem predominante
Shell
Estrelas
1.6k
Forks
627
Merge médio
2d 15h
PRs com merge (30d)
5

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de devcontainers/features

Todas as issues de devcontainers/features

Issues semelhantes

Mais issues de Shell/Bash

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.