I am currently exploring workarounds for the problem of processes started by kubectl exec not dying on disconnect described in my other question.

Here are a couple of observations. If I run the following script to see if the tty is still in a good state, I see that process believes the tty is always in a good state:

while true; do
sleep 1
if sh -c ": >/dev/tty" >/dev/null 2>/dev/null; then
    echo '/dev/tty is available and usable' >> /tmp/Result
    echo 'PTS output where'
else
    echo '/dev/tty is not available' >> /tmp/Result
fi
done

On the other hand, when I look at containerd logs in the node, I see these logs messages, which suggests that containerd is well aware that stdin and stdout are not functional.

journalctl -u containerd
level=info msg="Container exec "6ad3d92d21ac690f02ded22f9ee84cf272802bdde805bf79ea798f6cb86302a5" stdin closed"
level=error msg="Failed to pipe "stdout" for container exec "6ad3d92d21ac690f02ded22f9ee84cf272802bdde805bf79ea798f6cb86302a5"" error="read /proc/self/fd/93: file already closed"

Is there any programmatic way for the process (started by kubectl exec) running inside a container to learn this information from containerd?

For example, interrogating it directly via API call, making a system call, looking for a signal, or some other means?