Change:
[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/). {{< note >}} <del> Kubernetes only sends the preStop event when a Pod is *terminated*. This means that the preStop hook is not invoked when the Pod is *completed*. This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807). </del> <ins> Kubernetes only sends the preStop event when a Pod or a container in the Pod is *terminated*. This means that the preStop hook is not invoked when the Pod is *completed*. About this limitation, please see [Container hooks](docs/concepts/containers/container-lifecycle-hooks/#container-hooks) for the detail. </ins> {{< /note >}}

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In written as: But actually, preStop hooks are also invoked when container in a pod is terminated due to LivenesProbe/StartupProbe failure. This is something different from "when a Pod is terminated". Proposed Solution: fix doc: How can we reproduce it (as minimally and precisely as possible)? yaml file "Liveness-" a pod. livenessProbe failure by deleting log -preStop is invoked Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
If I understand the problem correctly then preStop hook is executed when Stop Event is sent to the container by the kubelet so if the preStop gets hanged or takes more time than graceTimeout it gets preStop hook failure event in pod logs
I guess if it encounter an return code != 0 from the preStop then crashLoopBackOff
Thank you for your comments. Your explanation helped me understand. I think doc is not correct strictly. what written in doc is a little bit different from actual behavior(and also what you explained). I suggest fix doc in PR :
I am just PR wrangler so you cannot make me to review pr sorry for that
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten