exec, attach, and logs

In one sentence: The shim owns the container's stdio pipes, teeing output to a log driver continuously and to any attached clients live — and exec runs a brand-new process inside the existing namespaces for debugging.

One producer, many consumers

The container writes to stdout/stderr exactly once; the shim fans it out. One permanent consumer — the log driver (file, journald, remote shipper), always on, which is why logs can show you output from before you asked. And zero or more live consumers: attach streams multiplex the same bytes to CLI clients over the API. Detaching just unsubscribes; the container never knows. The producer and consumers are fully decoupled — a slow attached client can't block the app.

flowchart LR
  C["container process
stdout / stderr"] --> SH["shim
(fan-out point)"]
  SH --> LD["log driver
always on → files / shipper"]
  SH --> AT["attach multiplexer"]
  AT --> U1["client 1 (live)"]
  AT --> U2["client 2 (live)"]
  LD --> LOGS[("stored logs
serves 'minidock logs'")]
  U3["stdin from attached client"] --> SH --> C
    

exec: a visitor, not a resident

exec answers "let me poke around inside." The engine asks the runtime to start a new process that joins the container's existing namespaces and cgroup — same fake world, same budgets — but it is not the app's child and its death doesn't touch the container's state machine:

sequenceDiagram
  participant U as Client
  participant E as Engine
  participant R as Runtime
  participant NS as c-42's namespaces
  U->>E: exec c-42 sh (interactive)
  E->>R: start process "sh" joining c-42's ns + cgroup
  R->>NS: enter PID, MNT, NET … then exec sh
  NS-->>E: exec process running (own stdio pipes)
  E-->>U: bidirectional stream (your keystrokes ↔ sh)
  U->>E: exit
  note over NS: sh dies; container app never noticed —
exec exit ≠ container exit