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

Ouverte
  • Quelque chose ne va pas ?
#1,765 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@v-Kaniska244 y travaille déjà.

Depuis le 5/11/2026.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
55/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
docker, go, shell
Domaine
devops, infrastructure

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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?

Langage dominant
Shell
Étoiles
1.6k
Forks
627
Merge moyen
1 j 19 h
PR mergées (30 j)
5

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de devcontainers/features

Toutes les issues de devcontainers/features

Issues similaires

Plus d'issues Shell/Bash

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.