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

Open
  • Is something wrong?
#1,765 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 3 days

@v-Kaniska244 is already working on this.

Since Nov 5, 2026.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, go, shell
Domain
devops, infrastructure

Research direction

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.

Written by the indexing model from the issue text.

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?

Dominant language
Shell
Stars
1.6k
Forks
626
Avg merge
4d 10h
Merged PRs (30d)
7

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from devcontainers/features

All issues in devcontainers/features

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.