Commands run via runc exec do not get killed when remote client disconnects

This has grown to become an issue in our kubernetes clusters: when a user has an exec shell inside a container and their connection dies, the command being executed inside the container does not die. We noticed this because many teams frequently use the kubernetes debug shell in the browser, and it's typical to just close the tab when complete instead of killing the command first. It also can be an issue for kube exec probes, where kubernetes implements timeouts by simply closing the exec session so exec probe commands can easily add up.

I understand that killing the process upon disconnection may not always be desirable, but it would be great if it were at least an option since it's basically impossible to implement a hack that can achieve this without help from runc: I looked into injecting a wrapper for exec commands that detects when the pty is closed and kills the child process, but I could not find any way to detect that the other end of the pty had hung up.

Start by tracing runc exec session handling and what happens when the remote client disconnects. Review the requested opt-in behavior and its implications for shells and exec probes. Done means an agreed configurable behavior, with the disconnect case covered by tests and documented for users.