chore: evaluate filing upstream issue for VCluster D-Bus race condition

[devantler]

Context

PR #2241 adds VCluster × Docker (Vind) support. During CI testing on GitHub Actions Ubuntu runners, the VCluster SDK's install-standalone.sh fails with:

failed to start vCluster standalone: exit status 1: Failed to connect to bus: No such file or directory

Root cause: The SDK runs systemctl restart systemd-journald inside the privileged Docker container before systemd has initialized D-Bus (/run/dbus/system_bus_socket). The container starts with --tmpfs /run, so the socket doesn't exist immediately. Combined with set -e, this aborts the install script.

This works on macOS (Docker Desktop provides a fully-initialized systemd VM) but fails on Linux CI runners due to a timing race.

Current workaround

KSail detects the "Failed to connect to bus" error from CreateDocker, waits for D-Bus readiness inside the container, then re-runs the install script. See recoverFromDBusError in pkg/svc/provisioner/cluster/vcluster/provisioner.go.

Action items

• Verify whether the D-Bus recovery workaround is needed after CI runs confirm the fix works
• If confirmed necessary, file an upstream issue on loft-sh/vcluster suggesting one of:
  • Adding a D-Bus readiness wait before systemctl restart systemd-journald in install-standalone.sh
  • Making the journald restart non-fatal (remove set -e or use || true)
  • Adding an SDK option to skip persistent logging setup
• Remove the workaround once an upstream fix is released

References

• install-standalone.sh line 333: systemctl restart systemd-journald
• VCluster SDK: github.com/loft-sh/vcluster v0.32.0-rc.1
• Chart version: 0.32.0-alpha.2

[github-actions]

✅ Agentic Triage completed successfully!

[botantler]

🎯 Agentic Issue Triage

This issue tracks a potential upstream contribution to the VCluster project regarding a D-Bus initialization race condition that affects Linux CI environments. The issue is well-documented with clear action items and context.

📋 Issue Summary

Type: Chore/Upstream tracking issue
Component: VCluster × Docker (Vind) provisioner
Severity: Low (workaround implemented)
Related PR: #2241 (VCluster × Docker support)

The VCluster SDK's install-standalone.sh script has a timing race where it attempts to restart systemd-journald before D-Bus is ready in Docker containers with --tmpfs /run. This manifests as Failed to connect to bus: No such file or directory on Linux CI runners but works on macOS (Docker Desktop's systemd VM is pre-initialized).

KSail currently implements a recovery workaround in recoverFromDBusError that detects the error and retries after waiting for D-Bus readiness.

🔍 Related Issues

This is part of a series of VCluster-related tracking issues:

• chore: track vCluster SDK stable release and replace RC dependency #2245 - Track vCluster SDK stable release (currently using RC)
• chore: remove loft-sh/log fork when upstream updates tablewriter to v1.x #2246 - Remove loft-sh/log fork when upstream supports configurable logging
• feat: investigate mirror registry support for VCluster distribution #2247 - Investigate mirror registry support for VCluster
• [feature]: Implement vCluster as a distribution, and use vind for the docker provider #2017 - Original VCluster implementation feature request

All are follow-up items from PR #2241 which adds VCluster × Docker support.

💡 Recommendations

For the team:

1. Wait for CI confirmation - The action items correctly prioritize verifying the workaround is necessary after CI runs complete
2. Gather evidence - Before filing upstream, collect CI logs showing the race condition and the workaround's effectiveness
3. Propose minimal fix - The suggested approaches are reasonable:
   • Option 1 (preferred): Add while [ ! -e /run/dbus/system_bus_socket ]; do sleep 0.1; done before the systemctl command
   • Option 2: Make it non-fatal with || true
   • Option 3: Add SDK configuration to skip persistent logging

Upstream issue template:
When filing, include:

• Environment details (Linux vs macOS, Docker version)
• Reproduction steps (GitHub Actions runner specifics)
• Proof that the race exists (timing logs)
• Your workaround code as reference
• One of the suggested fixes with rationale

Resources:

• [VCluster SDK Documentation]((www.vcluster.com/redacted)
• VCluster GitHub Issues
• [Systemd D-Bus activation]((www.freedesktop.org/redacted)
• [Docker tmpfs mounts]((docs.docker.com/redacted)

✅ Action Checklist

Before filing upstream:

• Confirm workaround is consistently needed across multiple CI runs
• Document specific VCluster SDK version where issue occurs
• Verify Docker version and runner OS details
• Check if newer vCluster versions (post v0.32.0-rc.1) still have the issue
• Test proposed fix in a fork if possible
• Prepare clear reproduction case for upstream maintainers
• Reference KSail's workaround implementation as proof of solution

After filing:

• Link the upstream issue in this GitHub issue
• Monitor upstream for responses
• Update workaround if upstream suggests alternative approach
• Schedule workaround removal after upstream fix is released and adopted

Labels applied: dependencies, go, blocked (blocked on CI confirmation and upstream response)

This is well-scoped technical debt tracking. The workaround is reasonable, and the upstream contribution path is clear.

AI generated by Agentic Triage

[github-actions]

New Failure Mode Detected: Exit Status 22

I've investigated CI run #5507 (https://github.com/devantler-tech/ksail/actions/runs/22412910603) which shows a different VCluster failure pattern from the D-Bus issue described in this issue.

Key Differences from D-Bus Issue

Aspect	This Issue (#2261)	New Failure (Run #5507)
Exit Code	1	22 (EINVAL)
Error Message	"Failed to connect to bus: No such file or directory"	"failed to start vCluster standalone: exit status 22"
Recovery	recoverFromDBusError triggers	No recovery - error substring doesn't match
Timing	Immediate failure	2-minute timeout (20:07:44 → 20:09:44)

Failure Details

Test: System Test (VCluster, Docker, false)
Failed Job: 64891814686
Commit: bd95a24 (PR #2488 - Hetzner secret race condition fix)

Successful Preliminary Steps:

• ✅ Created mirror registries (docker.io, ghcr.io, quay.io, registry.k8s.io)
• ✅ Created Docker network
• ✅ Loaded br_netfilter kernel module
• ✅ Pulled and extracted ghcr.io/loft-sh/kubernetes:v1.32.3-full
• ✅ Extracted vCluster binary from ghcr.io/loft-sh/vcluster-pro:0.32.0-alpha.2

Failure Phase:

20:07:44 info Starting vCluster standalone vcluster-default
[... 2 minute hang ...]
20:09:44 ✗ failed to execute cluster lifecycle: failed to create cluster: failed to create vCluster: failed to start vCluster standalone: exit status 22

Impact:

• No kubeconfig created
• Cluster delete command failed (no cluster name available)
• All subsequent VCluster and Talos tests cancelled
• Merge queue blocked

Analysis

Exit status 22 typically indicates EINVAL (Invalid argument) in Linux. The 2-minute timeout suggests the vCluster standalone startup script is waiting for something that never completes, then timing out.

This could be:

1. A different timing issue in the VCluster SDK's standalone startup
2. A systemd initialization failure (but different from D-Bus)
3. A resource constraint or Docker daemon issue
4. A regression in vCluster 0.32.0-alpha.2

Recommendation

Since this is a different failure mode from the D-Bus issue, it may require:

1. Additional error detection/recovery logic for exit status 22
2. Investigation of vCluster SDK standalone startup logs (if accessible)
3. Potentially filing a separate upstream issue if this is reproducible

The current recoverFromDBusError workaround won't help here since the error message doesn't contain "Failed to connect to bus".

Generated by CI Doctor

To install this workflow, run gh aw add githubnext/agentics/workflows/ci-doctor.md@1ef9dbe65e8265b57fe2ffa76098457cf3ae2b32. View source at https://github.com/githubnext/agentics/tree/1ef9dbe65e8265b57fe2ffa76098457cf3ae2b32/workflows/ci-doctor.md.