A metrics agent moved into its own container can no longer see the application process it watches — which fence did that, and what fixes it?

## What the process table fence actually does One of the fences a runtime composes gives a container its own view of the process table. Inside that view the container's first process is number one, and the only processes listed are its own descendants. Everything else on the machine — the host's processes and every other container's — is absent. "Absent" is stronger than "forbidden". This is not a permission check that a stronger identity would pass; the entries are not in the table being read. Consequently the watcher cannot enumerate the target, cannot signal it, cannot attach to it, and cannot read its memory or its per-process counters. A supervisor expecting to manage sibling processes finds none. A profiler that attaches by process id has nothing to attach to. A metrics agent that scrapes the process table reports an empty machine. ## Why moving the agent broke a setup that worked The agent worked when it ran beside the application, because both were in the same process table view — whether that was the host's view or a shared container's. Putting the agent in a container of its own gave it a *fresh* view, which is the default, and a fresh view contains exactly one thing: the agent. This is worth saying precisely in an interview, because the wrong diagnosis is so easy to reach. The usual wrong answers are "it needs more privilege" and "it needs the host's filesystem mounted". Neither addresses the fence. The agent is not being refused; it is looking at a different table. ## Three ways out, and what each costs 1. **Join the target's process view.** A runtime can start a container that, instead of getting a fresh process table view, joins one that already exists. The agent then sees the application's processes and can attach to and signal them. 2. **Collect from outside the boundary.** A collector running on the host sees every container's processes, because the host's view is the superset. One collector then serves every workload on the machine. 3. **Have the application publish.** The workload exposes what the agent needs on a socket, and the agent reads it over the network rather than out of a process table. | Approach | What it costs | |---|---| | join the target's process view | the fence between the two is gone, in both directions: a compromise of either reaches the other's processes | | collect from the host | the collector needs access to the host that a workload container should not have, and it sees ids that do not match the ones inside | | publish on a socket | the application has to be changed, and it can only publish what it already knows about itself | Note that sharing the process view is **mutual**. People reach for it thinking of it as "letting the agent in", but it is one view with two occupants: the application can equally list, signal and inspect the agent. That is precisely why a low-trust companion process is a poor candidate for sharing a view with something that holds credentials. ## Sharing one fence does not share the others The fences are independent, so a container that joins another's process view still has its own root filesystem, its own network view and its own host identity unless those are shared too. That trips people twice: - the agent can now **see** the target's processes but still cannot read files the target wrote, because the filesystems are separate; - inspecting another process's memory may still need a privilege the agent does not hold, because the fence being absent is not the same as authorisation being granted. Visibility is a precondition, not a permission. ## The ids do not line up Even once it works, the numbers disagree. The same process carries one number inside the container's view and a different one on the host, because each view numbers independently from one. An operator reading the host's table and an agent reading the container's will name the same process two different ways, and correlating them by number is a bug waiting to happen. Correlate by something stable instead — the workload's name, its instance identity, or a value the application reports about itself. ## What interviewers listen for The strong answer names the fence immediately rather than reaching for permissions, then presents the three options as a trade-off rather than picking one. The best version adds the direction check on the second option — sharing a view is mutual — because that is the sentence that separates someone who has configured this from someone who has read about it.