how would this happen?

conmon is setting set_subreaper() so that any child process, even not direct, is reported to conmon

It seems subreaper handles the normal case where process re-parenting works as expected. The problem is that in some systemd configurations, even with subreaper set container processes may not become direct children of conmon.

It seems subreaper handles the normal case where process re-parenting works as expected. The problem is that in some systemd configurations, even with subreaper set container processes may not become direct children of conmon.

how would that happen? conmon runs the OCI runtime that in turns runs the container. Every container process is a descendant of conmon

does it break when there are exec sessions?

Good catch! Let me add some bits to handle this.

@giuseppe Is it better now? Or is there anything else I missed?

I am not really a fan of the probe part, can we understand how that configuration happens? Because conmon should get the signal, even with exec sessions (the container exits, all the processes in the pid namespace are killed and their parent gets the sigchld)

Normally this would be the expected state:

systemd
  - crio-conmon-xxx.scope
    - conmon (subreaper)
      - OCI runtime (create_pid)
        - container process

But what happens in the case described in the issue is:

systemd
  - crio-conmon-xxx.scope
    - conmon (subreaper - isolated from container)
      - OCI runtime (create_pid, exits normally)
  - crio-xxx.scope
    - container process (moved by systemd, no longer child of conmon) 

So systemd moves the container process to the new scope after OCI runtime creates it but before OCI runtime exits. This seems to be why conmon receives the runtime exit signal (from runtime) but misses the container exit signal.

Does it make it any more clear?

how does the cgroup affect the parent->child relationship? I don't think it should matter in what cgroup the process ends up, it should still be reported to the conmon (assuming set_reaper() was used correctly) used for the exec session.

You can verify it by running podman run ...., then do podman exec ... and find in the process list the exec'ed process:

$ podman exec -lti sleep 12345 &
$ grep -i ppid /proc/$(pgrep -f 12345 | tail -n1)/status
PPid:   380778

and PPid is the conmon process.

Ok, let's keep the fix minimal - I removed the probe and left only the main part. @giuseppe PTAL

Comment adjusted, thanks!