You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug: surface supervisor startup failures to sandbox commands #3519
As an OpenShell operator, I want a sandbox command to report a meaningful startup failure so that I can diagnose failed sandbox launches without manually inspecting runtime logs.
Problem Statement
When a supervisor cannot start the workload entrypoint, the sandbox lifecycle is reduced to a generic container exit. For example, a rootless Podman run that fails to execute /bin/cat with Permission denied (os error 13) is reported by the CLI as ContainerExited with exit code 1. The useful error is only present in the supervisor container stderr; the workload log instead records the subsequent control-channel termination.
Impact / Why This Matters
Operators cannot distinguish an entrypoint execution failure from an ordinary workload exit through the OpenShell command result. The current workaround is to preserve failed containers and inspect Podman logs manually, which is runtime-specific, slow, and unsuitable for automated diagnostics.
Acceptance Criteria
A supervisor failure before sandbox readiness is represented as a distinct sandbox startup failure rather than only ContainerExited.
openshell sandbox create or run exposes a concise, sanitized diagnostic that identifies the failed startup stage and failure class.
The implementation does not propagate arbitrary workload or supervisor log output, credentials, or environment values into lifecycle status.
The behavior is covered by a unit or integration test for an entrypoint execution failure.
Reproduction Steps
Configure a rootless Podman gateway with the current restrictive sandbox policy.
Create a sandbox from Alpine with an explicit executable entrypoint, for example -- /bin/cat /proc/self/uid_map.
Observe the command fail with a generic container-exited status.
Inspect the supervisor container logs to find the underlying Permission denied (os error 13) spawn failure.
Environment
OpenShell: current main / Alpine-default work
OS: Fedora tmachine VM
Runtime: rootless Podman
Logs
Error: process error: boundary process leaf: start process supervisor leaf:
spawn delegated workload process
failed to spawn sandbox entrypoint process '/bin/cat'
Permission denied (os error 13)
Related Work
The Alpine-default work is being tracked in PR #3386. This issue is deliberately scoped to reporting the failure; the policy/entrypoint failure itself can be addressed independently.
Another startup failure that reaches the CLI only as a generic container exit, in case a second failure class helps with the design. In this one the useful error is in the workload container rather than the supervisor container.
On SUSE Linux Enterprise Server 15 SP7 (kernel 6.4.0-150700.53.81-default, built without CONFIG_SECURITY_LANDLOCK), with OpenShell 0.1.2 installed from the RPMs and the rootless Podman driver (Podman 4.9.5), openshell sandbox create --name demo -- true fails after about 6 seconds with:
Error: × sandbox entered error phase while provisioning: ContainerExited: Container
│ exited with code 1
openshell sandbox get demo adds nothing beyond Ready: False (ContainerExited) - Container exited with code 1.
The cause is only in podman logs of the workload container (openshell-default--demo-<id>, entrypoint openshell-sandbox launch-capability-free):
The supervisor container's log has nothing about it. On SLES 16.0 (kernel 6.12, Landlock ABI 6) the same setup starts sandboxes normally.
Two notes for the fix:
It would need to cover failures in the workload-side launcher before readiness, not only supervisor errors.
This fits the acceptance criteria as they are. A stage plus a failure class, for example "sandbox startup: Landlock unavailable in the host kernel", would be enough to act on without forwarding raw log output. Missing host prerequisites like this one are a common first-run failure on a new platform, so this may be worth its own class next to the entrypoint execution failure.
Related: #4133 covers detecting missing Landlock up front with doctor check for Docker and Podman, and a clearer Landlock error inside the sandbox. This issue would still be needed to get that error to the CLI.
Activity
gusraggio commentedon Oct 5, 2026
Another startup failure that reaches the CLI only as a generic container exit, in case a second failure class helps with the design. In this one the useful error is in the workload container rather than the supervisor container.
On SUSE Linux Enterprise Server 15 SP7 (kernel
6.4.0-150700.53.81-default, built withoutCONFIG_SECURITY_LANDLOCK), with OpenShell 0.1.2 installed from the RPMs and the rootless Podman driver (Podman 4.9.5),openshell sandbox create --name demo -- truefails after about 6 seconds with:openshell sandbox get demoadds nothing beyondReady: False (ContainerExited) - Container exited with code 1.The cause is only in
podman logsof the workload container (openshell-default--demo-<id>, entrypointopenshell-sandbox launch-capability-free):The supervisor container's log has nothing about it. On SLES 16.0 (kernel 6.12, Landlock ABI 6) the same setup starts sandboxes normally.
Two notes for the fix:
Related: #4133 covers detecting missing Landlock up front with
doctor checkfor Docker and Podman, and a clearer Landlock error inside the sandbox. This issue would still be needed to get that error to the CLI.