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

  1. Read the daemon message embedded in the error — it usually names the concrete problem (e.g. 'container is not running')
  2. Verify the container remained running for the whole listing and retry on a live container
  3. Check daemon logs (`journalctl -u docker`) for the corresponding internal error
  4. 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

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


AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01). Data as JSON: /api/errors/b193fb5cab5c15ee. Report an issue: GitHub.