Your bpftrace one-liner runs fine as root on a Linux host but fails to load when you run it inside a container, and when you run it from the host against a containerised workload the PIDs and file paths it prints do not match what you see inside the container. Explain both problems and how you would work around each.

## Problem one: it will not load in a container Loading and attaching a BPF tracing program is a privileged kernel operation, and a container is deliberately configured to prevent privileged kernel operations. Several independent barriers apply, and you usually hit more than one: - **Seccomp.** The default profile applied by mainstream container runtimes blocks `bpf(2)` and `perf_event_open(2)`. Even a container running as root with capabilities intact will get `EPERM` from the system call itself. - **Capabilities.** Loading tracing programs and attaching to perf events requires `CAP_BPF` together with `CAP_PERFMON` on Linux 5.8 and later, or `CAP_SYS_ADMIN` before that. Containers drop these by default. Attaching uprobes and reading process memory can additionally involve `CAP_SYS_PTRACE`. - **Filesystem visibility.** bpftrace and bcc want tracefs (`/sys/kernel/tracing`, historically under `/sys/kernel/debug/tracing`) to enumerate tracepoints, and BTF at `/sys/kernel/btf/vmlinux`. Neither is normally mounted or readable inside a container. - **sysctls.** `kernel.perf_event_paranoid` and `kernel.unprivileged_bpf_disabled` are host-wide knobs that a container cannot change, and hardened hosts set them restrictively. You *can* force it — a privileged container with the seccomp profile unconfined and the host's tracefs and BTF bind-mounted in. That is exactly how packaged eBPF tooling images are run. But recognise what you have done: a container with the ability to load kernel programs and read arbitrary kernel memory has effectively host-level power, so this is a deliberate, audited exception, not a convenience. The better default is to trace **from the host**. eBPF instrumentation is kernel-global: a probe on a syscall tracepoint sees every process on the machine, containerised or not, because namespaces virtualise identifiers and views, not the kernel code paths themselves. Nothing is hidden from you by the container; the question is only whether you can interpret what you see. ## Problem two: the identifiers do not line up **PIDs.** A container's processes live in their own PID namespace, where the entry point is PID 1. From the host the same process has a different, larger PID. The built-ins bpftrace exposes report the value in the *initial* PID namespace — the host's view — because that is what the kernel's task structures use as the global identity. So a trace that prints `pid` gives you numbers that match `ps` on the host and the runtime's own process listing, and that will not be found by `ps` inside the container. Translating goes through `/proc/<hostpid>/status`, whose `NSpid` line lists the process's id in each nested namespace. This is not a bug and it is usually what you want during an incident: you are on the host, you want host identifiers, and they let you go straight to `/proc/<hostpid>/`. **Paths.** A filename argument captured at a syscall is a string in the caller's context, resolved against the *caller's* mount namespace. If a container has its own root filesystem, `/app/config.yaml` is a perfectly valid path there and does not exist at that location on the host. To open the file the traced process opened, go through the host's view of that process's root: ``` /proc/<hostpid>/root/app/config.yaml ``` The same applies in reverse to anything you supply — a uprobe target path must be a path *the host* can resolve, so you name the binary via `/proc/<hostpid>/root/...` rather than the path the container sees. **Mounted-over and overlay paths.** With an overlay root filesystem, the file the process opened may correspond to a file in a lower layer or in the upper directory, so the host-side location under the storage driver's directories is not somewhere to reason about; `/proc/<hostpid>/root/` is the reliable route because the kernel resolves it in the target's own namespace. ## Scoping a trace to one container Since the probe is machine-wide, you need a predicate that means "this container". Options, roughly in order of robustness: - **Filter by cgroup.** Every container's processes sit in a distinct cgroup v2 subtree, and bpftrace can compare the current task's cgroup identifier against the id of a named cgroup path. This is the most durable filter, because it survives processes forking inside the container. - **Filter by the set of host PIDs.** Obtain them from the runtime's process listing or from the cgroup's `cgroup.procs` file, then filter on `pid`. Simple, but misses processes that start after you began. - **Filter by `comm`.** Convenient and often ambiguous, since another container may run the same binary. Use it to narrow, not to scope. ## The checklist When a trace "does not work" around containers, walk it in this order: can the program load at all (privileges, seccomp, tracefs, BTF); am I in the right vantage point (host, almost always); are the identifiers I am reading in the namespace I think they are (they are the host's); and is my filter actually selecting the workload (cgroup rather than name).