You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the list of supported hooks, we are missing a hooks for configuring custom actions related to the exit lifecycle ( i.e normal exist / killing a container ..)
In nerdctl project, we need a hooks to deal with container deps when the container exit, such as cleaning some state files.
PostExit should be called after the container exit
How implementable?
did not get your question ? You mean how to introduce a runtime implementation. If yes I believe that we can easily do this in runc for example, but I have to dig into before answering this question.
@AkihiroSuda would please give me more details about exec(2)-ing the container process or may be link code or article around this. I am looking for an entrypoint to understand what are saying. thanks
@AkihiroSuda would please give me more details about exec(2)-ing the container process or may be link code or article around this. I am looking for an entrypoint to understand what are saying. thanks
In contrast to foreground mode, in detached mode there is no long-running
foreground runc process once the container has started. In fact, there is no
long-running runc process at all.
@AkihiroSuda would please give me more details about exec(2)-ing the container process or may be link code or article around this. I am looking for an entrypoint to understand what are saying. thanks
In contrast to foreground mode, in detached mode there is no long-running
foreground runc process once the container has started. In fact, there is no
long-running runc process at all.
got the point. Do we have a hook mechanism into containerd that may catch container exit ?
There was a discussion about this topic many years ago (before 1.0), but I can't seem to find the discussion thread... EDIT: #926 is related but there was a longer thread where someone actually proposed a prototype, which is the thread I can't find.
IMHO postexit hook should work the same way the poststop hook does. But trigger on exit, not delete.
You appear to have a misunderstanding of how OCI runtimes work -- after the container is started, there is no guarantee that there is any monitor process from the OCI runtime that can catch the container exit. In runc's case, this happens when you run in detached mode (which how all the higher-level runtimes use runc). This means that there is no runc code that could detect the exit and spawn a hook!
In contrast, poststop works because runc delete needs to be run in order to delete the container. (The name is unfortunately quite misleading -- almost all of the old hook names are.)
Higher-level runtimes can detect exits because they implement their own process monitors (containerd has containerd-shim, podman has conmon, etc). runc does not have a built-in process monitor (unlike LXC) which means there is no way for us to run a hook at the instant a container dies.
Back in the 2010s there were proposals to do this on a best-effort basis (for instance, the next time a runc command is called we detect all containers that died and run their post-stop hooks) but this has all sorts of awful issues (permissions, possibilities of a DoS, correctness) that is just doesn't make sense.
Activity
AkihiroSuda commentedon Feb 14, 2023
Did you mean "exist" or "exit" ?
AkihiroSuda commentedon Feb 14, 2023
And how would it be different from
poststophooks?fahedouch commentedon Feb 14, 2023
@AkihiroSuda
Yes
exitpoststophook is called after the container is deleted but before the delete operation returns.PostExitshould be called after the container exitAkihiroSuda commentedon Feb 14, 2023
How implementable?
fahedouch commentedon Feb 14, 2023
did not get your question ? You mean how to introduce a runtime implementation. If yes I believe that we can easily do this in
runcfor example, but I have to dig into before answering this question.AkihiroSuda commentedon Feb 15, 2023
An OCI runtime process disappears on exec(2)-ing the container process, so I'm not sure how this proposal is implementable.
fahedouch commentedon Feb 15, 2023
@AkihiroSuda would please give me more details about
exec(2)-ing the container processor may be link code or article around this. I am looking for an entrypoint to understand what are saying. thanksAkihiroSuda commentedon Feb 15, 2023
https://github.com/opencontainers/runc/blob/v1.1.4/docs/terminals.md#detached
fahedouch commentedon Feb 21, 2023
got the point. Do we have a hook mechanism into containerd that may catch container exit ?
AkihiroSuda commentedon Feb 21, 2023
Feel free to submit a proposal in the containerd repo.
Maybe we can extend its restart monitor plugin.
fahedouch commentedon Feb 25, 2023
opened ticket containerd/containerd#8163
Elthis commentedon Mar 3, 2026
@fahedouch
Hmm, I've recently was going through containerd source code and noticed that they are monitoring if container exited:
https://github.com/containerd/containerd/blob/f4681e01d0fab33ccb2a88dc9c255b5cb4eba1ea/internal/cri/server/events.go#L173
So containerd has a way to monitors container exit and acts upon it (updates internal container status as stopped and fills the exit information).
Maybe this would allow to push this issue further?
IMHO postexit hook should work the same way the poststop hook does. But trigger on exit, not delete.
This would be useful, since OCI container delete times differ between different CRI:
See cri-o/cri-o#9732
cyphar commentedon Mar 3, 2026
There was a discussion about this topic many years ago (before 1.0), but I can't seem to find the discussion thread... EDIT: #926 is related but there was a longer thread where someone actually proposed a prototype, which is the thread I can't find.
You appear to have a misunderstanding of how OCI runtimes work -- after the container is started, there is no guarantee that there is any monitor process from the OCI runtime that can catch the container exit. In runc's case, this happens when you run in detached mode (which how all the higher-level runtimes use runc). This means that there is no runc code that could detect the exit and spawn a hook!
In contrast,
poststopworks becauserunc deleteneeds to be run in order to delete the container. (The name is unfortunately quite misleading -- almost all of the old hook names are.)Higher-level runtimes can detect exits because they implement their own process monitors (containerd has containerd-shim, podman has conmon, etc). runc does not have a built-in process monitor (unlike LXC) which means there is no way for us to run a hook at the instant a container dies.
Back in the 2010s there were proposals to do this on a best-effort basis (for instance, the next time a runc command is called we detect all containers that died and run their post-stop hooks) but this has all sorts of awful issues (permissions, possibilities of a DoS, correctness) that is just doesn't make sense.
Elthis commentedon Mar 3, 2026
Aww, okay. I guess I understand the problem now.
Thanks @cyphar for the descriptive answer.