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

Aperta
  • Qualcosa non va?
#1,765 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@v-Kaniska244 ci sta già lavorando.

Dal 5/11/2026.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
docker, go, shell
Ambito
devops, infrastructure

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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?

Lingua principale
Shell
Stelle
1.6k
Fork
627
Merge medio
1g 19h
PR unite (30g)
5

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di devcontainers/features

Tutte le issue di devcontainers/features

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.