Skip to content

fix flb_utils test in docker environments #11098

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix flb_utils test in docker environments #11098

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion .devcontainer/devcontainer.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,8 @@
]
}
},

"mounts": [
"source=/etc/machine-id,target=/etc/machine-id,ro,type=bind,consistency=cached"
],
Comment on lines +36 to +38
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Avoid unconditional mount of host machine-id

The new mounts entry assumes /etc/machine-id exists on the host, but many contributors use Docker Desktop on macOS or Windows where that file is absent. In those environments docker run will refuse to start the dev container because the bind source does not exist, rendering the default devcontainer unusable. This solves the WSL case but regresses other platforms; consider making the mount optional or creating the file when present instead of requiring it globally.

Useful? React with 👍 / 👎.

Comment on lines +36 to +38
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify devcontainer mounts behavior when /etc/machine-id is absent.

The new mounts configuration binds /etc/machine-id from the host into the container. This directly addresses the stated problem of unstable machine-id in the test environment. However, confirm the following:

  1. Syntax correctness: Verify the mount string format is valid for devcontainer (it appears correct, but consult official devcontainer spec if unsure).
  2. Host file existence: Clarify the behavior if /etc/machine-id does not exist on the host system—will the container fail to start, or will the mount silently fail/be skipped?
  3. Alternative locations: The PR description notes some systems have machine-id in /var/lib/dbus/machine-id. Consider whether a second mount entry would improve robustness, or document this known limitation.

The fix looks sound for the target environment (WSL/devcontainer). Run this verification to confirm the mount syntax is correct per the devcontainer specification:

🏁 Script executed:

#!/bin/bash
# Description: Verify the mounts syntax in devcontainer.json against the spec.

# Check if the JSON is valid
jq empty .devcontainer/devcontainer.json && echo "JSON is valid"

# Extract and display the mounts section for manual inspection
jq '.mounts' .devcontainer/devcontainer.json

Length of output: 113

🏁 Script executed:

#!/bin/bash
# Display the first ~10 lines to identify the parse error at line 5, col 4
echo "=== First 15 lines of devcontainer.json ==="
head -15 .devcontainer/devcontainer.json

echo -e "\n=== Lines 30-45 (mounts section) ==="
sed -n '30,45p' .devcontainer/devcontainer.json

echo -e "\n=== Full file with line numbers ==="
cat -n .devcontainer/devcontainer.json

Length of output: 2340

🌐 Web query:

devcontainer.json mounts syntax specification format

💡 Result:

Short answer

  • In devcontainer.json, "mounts" is an array. Each entry may be:
    • A string using Docker CLI --mount syntax (key=value pairs separated by commas): e.g. "source=/host/path,target=/container/path,type=bind,consistency=cached". [1]
    • Or a JSON object with fields like type, source, target (and optional bind/volume/tmpfs options): e.g. { "type": "volume", "source": "my-vol", "target": "/data" }. [2]

Notes

  • The string form accepts the same options as Docker's --mount (and supports VS Code variable interpolation like ${localEnv:...} and ${localWorkspaceFolder}). [1][3]
  • Use bind for host paths, volume for named volumes, tmpfs for tmpfs, etc.; consistency/read_only and other mount-specific options follow Docker semantics. [1][2]

Sources
[1] VS Code / devcontainers docs (mount examples and --mount string form).
[2] microsoft/vscode devcontainers examples & issues (object-form example and fields).
[3] VS Code docs / metadata reference (notes on interpolation and behavior).

🌐 Web query:

devcontainer.json comments support JSON5

💡 Result:

Short answer: Yes — devcontainer.json supports comments, but via JSONC (JSON with comments), not necessarily full JSON5 syntax. Use // or /* */ comments and keep the file as JSONC; if you run a linter, set its file type to JSONC (not strict JSON). [1][2][3]

Sources:

  • VS Code / Dev Containers docs: devcontainer.json is "JSONC (JSON with comments)". [1]
  • GitHub Codespaces docs: devcontainer.json written using JSONC; linters should be set to JSONC. [2]
  • JSON5 spec (for comparison): JSON5 allows comments plus other extensions (unquoted keys, trailing commas, etc.). [3]

---

🌐 Web query:

```web
Docker devcontainer bind mount fails if source file missing behavior

💡 Result:

Short answer

  • Docker bind mounts require the host path (file or directory) to exist when using --mount (the daemon will error if the source is missing). VS Code Dev Containers passes mounts through to Docker, so you get the same failure. [1][2][3]
  • Behavior differences: the legacy -v/--volume syntax will create a missing host path (as a directory) in some cases; the --mount long form will not — it errors instead. For swarm services a host bind path must exist on every node. [3][2]
    What to do
  • Create the file/path on the host before opening the devcontainer (mkdir/touch or a prep script), or use a named Docker volume/volume mount instead of a host-file bind if you need automatic creation. [4][2]

Sources

  1. VS Code / devcontainer example showing Docker error when source empty. [turn0search0]
  2. "Invalid mount config for type 'bind': bind source path does not exist" — documentation/answers explaining host path must exist (and swarm behavior). [turn1search0]
  3. Explanation of difference between -v/--volume and --mount (--mount does not auto-create; -v may). [turn1search4]
  4. Practical guidance (create file beforehand / scripts) and examples. [turn1search3]

Docker bind mount will fail container startup if /etc/machine-id is missing on the host.

The mount syntax is valid per devcontainer specification, using correct Docker --mount format. However, Docker's --mount (used by Dev Containers) requires the source path to exist on the host—if /etc/machine-id is absent, the devcontainer will error during startup rather than silently skip the mount.

This breaks the devcontainer for systems without /etc/machine-id (noted in the PR as a known limitation on some systems). Consider:

  • Document the requirement clearly in README or devcontainer.json comments so users on affected systems understand they need to create the file.
  • Use a named volume instead of a bind mount if a fallback for missing host files is needed.
  • Add a setup script to create /etc/machine-id if missing (though this may not align with the read-only intent).
🤖 Prompt for AI Agents 
.devcontainer/devcontainer.json lines 36-38: the current bind mount of
/etc/machine-id will cause container startup to fail on hosts where that file
doesn't exist; update the setup to avoid a hard host bind or document the
requirement. Fix options: (1) replace the host bind with a named volume (e.g.,
source=devcontainer-machine-id,type=volume,target=/etc/machine-id) and add a
postStartCommand or Dockerfile step to populate the file inside the container if
the volume is empty; or (2) remove the mount and document in README that
/etc/machine-id must exist on the host before starting the devcontainer (with
clear creation instructions), or (3) add a devcontainer postCreateCommand script
that checks for /etc/machine-id and creates it on the host prior to mounting (if
you choose to keep the bind) — implement one of these fixes and update
devcontainer.json and README accordingly.

"remoteUser": "fluent-bit"
}