## TL;DR
Your eBPF profiler is blaming the wrong container because it resolved a recycled PID or a stale cgroup ID to the container that used to own it. On a shared host with short-lived containers, attribution must come from the cgroup the sample was taken in, not from a PID looked up later. Fix the profiler's container-ID resolution and verify against per-container CPU from the cgroup stats.

```text
agent's eBPF profiler attributed kernel time to the wrong container on a shared host
```

1. Sanity-check the accusation. Compare the profiler's per-container CPU against cgroup CPU stats for the same window. Expected: they disagree; the cgroup stats show the real consumer.
2. Look for PID and cgroup reuse. Short-lived containers churn PIDs and cgroup IDs fast, and a profiler that resolves IDs lazily maps samples to whatever container holds the ID now. Expected: the wrongly blamed container started recently, or the real consumer already exited.
3. Fix the resolution. Configure the profiler to attribute from the cgroup ID captured at sample time, in the container's own mount and PID namespace context, and to refresh its container map on cgroup create and destroy events. Expected: per-container numbers start matching cgroup stats.
4. Verify on a shared host under churn. Run a known CPU burner in one container while others sit idle, with containers starting and stopping around it. Expected: the burner is blamed every time, including across container restarts.

## Use this when
- One container shows impossible CPU usage while neighbors look idle
- The blamed container's own application metrics show no corresponding work
- Containers on the host are short-lived or churning

## Not for this skill when
- Cgroup stats agree with the profiler: then the container really is hot
- Each container has a dedicated host: there is nobody to misattribute to

## Variant phrasings
- "ebpf profiler wrong container CPU attribution"
- "profiler shows CPU in the wrong docker container"
- "shared host profiler blaming idle container"

## Why it happens
Kernel samples carry PIDs, and PIDs get recycled; cgroup IDs get reused when containers churn. A profiler that captures the ID at sample time but resolves it to a container name later, or that reads it from the host PID namespace while the container lives in its own, quietly hands one container's CPU bill to another. The busier the churn, the more often it lies.

## Edge cases
- PID namespaces mean the same numeric PID exists in many containers at once: host-namespace resolution without the namespace context is always suspect
- Container runtimes that pause and resume containers can produce samples with no live owner at all
- Kernel time (syscalls, page faults, network stack) is the hardest to attribute and the first to go wrong; user-space stacks are more robust

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W9swsCqtxTxt3i-kh3mTNA