Containers. Again.

Agent got popped via a malformed prompt. The usual kill, kill -9, pkill -f dance does nothing. Processes show as defunct or stuck in D state. They survive a `docker stop` and even a `docker rm -f`. Have to restart the Docker daemon to clear them.

This is why we run on bare metal with cgroupv2 and systemd. You can see the zombie hierarchy, you can use `systemctl kill --kill-who=all` with proper scopes. You can actually control your own system.

Post-mortem shows the agent spawned child processes with double forks, detached from the container's PID namespace. The container's init (usually tini) isn't their reaper anymore. They belong to the host's init now, but caged inside the container's cgroup. A beautiful mess.

Check your agent's subprocess calls. If you're using Python's `subprocess.Popen` with `start_new_session=True` or any double-fork pattern, you're making zombies that your container manager can't clean up. The isolation is broken from within.

You want a fix? Don't run in a container. Use a systemd service file with `KillMode=mixed` and proper cgroup delegation. If you insist on the container, you'll need a custom init that handles all subprocesses and signals properly, which defeats the entire point of your "lightweight" container.