> The only places in cri-o where `CONTAINER_STOPPED_EVENT` is generated are :

• server.go:899, during handleExit(). There's no check on the status of the container, the only other exit paths are for internal errors. To me, it means this event is generated whenever the container exits, whether or not it goes to completion?

handleExit() handles containers that CRIO thinks have exited (in other words run to completion). It handles both regular containers as well as sandboxes that have run to completion.

• sandbox_stop_linux.go:97 for the sandbox only, when the stopPodSandbox() function is called. Again, I'm not sure it takes the completion into account, it just stops everything.

@sairameshv This looks like a bug. We shouldn't really generate ContainerEventType_CONTAINER_STOPPED_EVENT in that file. That's not where we detect the sandbox has run to completion (exited). handleExit() function gets invoked when crio gets notified (using fsnotify) that the container has exited and we are already emitting ContainerEventType_CONTAINER_STOPPED_EVENT there.

Shouldn't we check the status of the container in handleExit() before sending the event, if the event depends on the completion? Or am I missing something about what the "completion" status is?

Container running to completion or exited mean same thing. In broad sense, it's just means that the container has terminated itself without kubelet asking for that action. The runtime has already determined that container has terminated (with the help of fsnotify). We just want to convey that information to the kubelet when Evented PLEG is turned on.

The fact that we generate CONTAINER_STOPPED_EVENT on stopPodSandbox() and not stopContainer() is part of why I made this change in the first place - I expected them to be symmetric somehow. If we're not supposed to send CONTAINER_STOPPED_EVENT on stopContainer(), should we remove it from stopPodSandbox() too? If not, why?

stopPodSandbox also should not emit CONTAINER_STOPPED_EVENT.

Also, stop container should not emit CONTAINER_DELETED_EVENT, it should be only emitted from container_remove.go

I'm sorry if these are dumb questions, but I'm really trying to understand what's expected before changing anything for the kata-specific use case.

No problem. Evented PLEG is a very new feature and you are already helping us discover the bugs in our current implemention. So thanks a lot for that.

Originally posted by @harche in #6531 (comment)