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

Offen
  • Stimmt etwas nicht?
#1,765 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
docker, go, shell
Bereich
devops, infrastructure

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?

Vorherrschende Sprache
Shell
Sterne
1.6k
Forks
627
Ø Merge
1 T. 19 Std.
Gemergte PRs (30 T.)
5

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus devcontainers/features

Alle Issues in devcontainers/features

Ähnliche Issues

Weitere Issues zu Shell/Bash

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.