Interestingly, I've never seen it, either in CI or locally. I see that you're using cgroupv1 -- any other details that might be relevant for a repro?

e.g. kernel version and distro?

Another flaky I saw in github action:

not ok 120 kill KILL [host pidns + init gone]
# (from function `test_host_pidns_kill' in file tests/integration/kill.bats, line 56,
#  in test file tests/integration/kill.bats, line 124)
#   `test_host_pidns_kill' failed
# runc spec (status=0):
#
# runc run -d --console-socket /tmp/bats-run-WwMIyU/runc.coexOx/tty/sock test_busybox (status=0):
#
# pids: 76212
# 76236
# 76253
# 76270
# 76288
# 76305
# /home/runner/work/runc/runc/tests/integration/kill.bats: line 56: kill: (76212) - No such process

Maybe we should wait some time to see cgroup.procs after we kill a pid.

This last one is different from the previous few (it was line 66 before). Now it is this:

(from function `test_host_pidns_kill' in file tests/integration/kill.bats, line 56,

Here is it:

What's happening here is:

• we start a container
• exec a few sleep processes in it
• kill container's init
• check that these processes are still there

Ah! I think what happens is we kill init, but its pid is still listed in cgroup.procs.

Now, the older failures (line 66) are happening because this code:

For both cases, I can't think of anything but to add a sleep after kill.

Should be fixed by #4179. As much as I don't like adduing kludges like this, I can't think of any other way to solve this.

For both cases, I can't think of anything but to add a sleep after kill.

I was wrong. If the pid is known, one can wait in loop doing kill -0 (if the pid is known), or, for newer linux kernels, use pidfd event reporting. Let me see what I can do.

For both cases, I can't think of anything but to add a sleep after kill.

I was wrong. If the pid is known, one can wait in loop doing kill -0 (if the pid is known), or, for newer linux kernels, use pidfd event reporting. Let me see what I can do.

Implemented via kill -0 in a loop to wait for the process to be gone.

I think that maybe it's better to implement it in runc (rather than the test case). IOW make runc kill (and runc delete -f) synchronous. This should fix some corner cases, e.g. killing the container and creating a new one using the same cgroup, but the cgroup is not (yet) empty.