vxcontrol/pentagi · error
docker exec systemerr: %s
Error message
docker exec systemerr: %s
What it means
Docker's multiplexed exec stream can carry a systemerr frame (stream id 3) containing a daemon-level error message injected mid-stream. demuxExecStdout surfaces that message verbatim (trimmed) as an error, since it indicates the daemon itself reported a problem with the exec, not command output.
Source
Thrown at backend/pkg/docker/client.go:1088
// dropping the tail.
return nil, fmt.Errorf("truncated exec stream: %w", err)
}
size := int64(binary.BigEndian.Uint32(header[4:8]))
if size == 0 {
continue
}
switch header[0] {
case 1: // stdout
if _, err := io.CopyN(&stdout, r, size); err != nil {
return nil, err
}
if stdout.Len() > maxStdout {
return nil, fmt.Errorf("listing output exceeded %d bytes", maxStdout)
}
case 3: // systemerr — a daemon-level error injected mid-stream; surface it
var msg bytes.Buffer
_, _ = io.CopyN(&msg, r, size)
return nil, fmt.Errorf("docker exec systemerr: %s", strings.TrimSpace(msg.String()))
default: // stderr and anything else — discard
if _, err := io.CopyN(io.Discard, r, size); err != nil {
return nil, err
}
}
}
return stdout.Bytes(), nil
}
type statFailure struct {
name string
err error
}
// statContainerEntries stats every name concurrently, bounded to `workers`
// in-flight calls. A per-entry stat error never aborts the batch: the successful
// stats and the failures are both returned (in input order) so the caller can
// serve a partial listing rather than discarding everything on one bad entry.View on GitHub (pinned to ea665308ba)
Solutions
- Read the daemon message embedded in the error — it usually names the concrete problem (e.g. 'container is not running')
- Verify the container remained running for the whole listing and retry on a live container
- Check daemon logs (`journalctl -u docker`) for the corresponding internal error
- Prevent concurrent restarts/removals of the container while listings are in flight
Defensive patterns
Strategy: try-catch
Validate before calling
state, err := dc.ContainerInspect(ctx, containerID)
if err != nil || !state.State.Running {
return fmt.Errorf("container must be running before listing")
} Try / catch
listing, err := client.ListContainerDir(ctx, containerID, dir)
if err != nil {
if msg, ok := extractSystemerrMessage(err); ok {
log.Printf("docker daemon reported: %s", msg)
return retryAfterContainerCheck(ctx, containerID, dir)
}
return err
} Prevention
- Keep containers running for the duration of introspection
- Check daemon logs when systemerr messages recur
- Avoid orchestrator restarts racing with exec-based operations
- Monitor host memory pressure to prevent daemon kills
When it happens
Trigger: The Docker daemon injects a systemerr frame, e.g. the container was stopped/removed while the exec was running, the exec process was killed by the daemon, or the daemon hit an internal error streaming the exec.
Common situations: Container stopped or restarted by an orchestrator (docker restart policy, compose down) during the listing; host under memory pressure killing the exec; daemon upgrades/restarts mid-stream.
Related errors
- failed to attach list exec for '%s': %w
- failed to read list output for '%s': %w
- truncated exec stream: %w
- failed to list images: %w
- failed to copy output: %w
AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01).
Data as JSON: /api/errors/b193fb5cab5c15ee.
Report an issue: GitHub.