Answers: <p>I want to add a quick and dirty solution to this. I often add <code>sleep 600</code> to the end of a command that's failing unexpectedly so that I can <code>exec</code> in and poke around to see what happened. Yaml example (note: <code>- &gt;-</code> enables multi-line concatenation, just a convenience):</p>
  <pre><code>        command: [&quot;bash&quot;, &quot;-c&quot;]
          args:
            - &gt;-
              python myscript.py; sleep 600;
  </code></pre>
  <p>With that said, Karthick's answer is better, this is just a simple solution that doesn't follow best practices. I encourage you <strong>not</strong> to use <code>sleep</code> or <code>sleep infinity</code>, because it's very easy to forget that your pod is running and holding onto resources indefinitely.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-09-07T08:30:08.483Z
Answers: This is the better solution. The above is just the usual rubbish about getting Kubernetes unhelpful status messages
Answers: MikeKulls
Answers: CC BY-SA 4.0
Answers: 2021-12-27T17:49:17.897Z
Answers: 2022-09-07T18:42:34.883Z
Answers: 2022-09-07T18:42:34.883Z
Answers: David Parks
Answers: <p>Keeping your pod alive after its main process exited is an anti-pattern and not possible in K8s.</p>
  
  <p>The entire concept of a K8s Job is to run till completion. So what you are looking to do is neither ideal nor recommended.</p>
  
  <p>It would be better to change the entrypoint command of your container to include a retry/error handling mechanism in case of failure.</p>
  
  <p>With that said, you do have ways in which you can <strong>debug</strong> the failed pod.</p>
  
  <p>If your Pod's container process exits due to error, the Pod will be marked with <code>Status: Failed</code></p>
  
  <p>But you can still debug the failed pod by attaching an Ephemeral container: <a href="https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container</a></p>
  
  <p><strong>Note:</strong> Ephemeral containers are available as K8s alpha feature only from v1.16</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-08-29T09:44:12.580Z
Answers: If you're using Docker Desktop as your local Kubernetes cluster, you can set the flag by modifying the kubeadm manifest files, as [seen here](https://stackoverflow.com/a/68971526/2441655).
Answers: Venryx
Answers: CC BY-SA 4.0
Answers: 2020-05-31T06:13:20.240Z
Answers: 2020-05-31T06:13:20.240Z
Answers: Karthick Prabu
Body: <p>After starting a long running kubernetes job we've found that the final result will fail to upload to its final location. We would like to force the pod to stay open after the main process fails so we can exec in and manually process the final results. If the main process fails and the pod exits before uploading the final result we will lose a large amount of time to re-process the job.</p>
  
  <p>Is there a way to ensure the pod stays alive manually?</p>
  
Tags: <kubernetes>
Title: Can a kubernetes pod be forced to stay alive after its main command fails?
UserDisplayName: David Parks
ThreadText: # Can a kubernetes pod be forced to stay alive after its main command fails?
  
  (Asked by: username_0 on 2020-05-30)
  
  After starting a long running kubernetes job we've found that the final result will fail to upload to its final location. We would like to force the pod to stay open after the main process fails so we can exec in and manually process the final results. If the main process fails and the pod exits before uploading the final result we will lose a large amount of time to re-process the job.
  
  Is there a way to ensure the pod stays alive manually?
  
  **Tags:** kubernetes
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2020-05-31. Score: 3 | Accepted answer
  
  Keeping your pod alive after its main process exited is an anti-pattern and not possible in K8s.
  
  The entire concept of a K8s Job is to run till completion. So what you are looking to do is neither ideal nor recommended.
  
  It would be better to change the entrypoint command of your container to include a retry/error handling mechanism in case of failure.
  
  With that said, you do have ways in which you can **debug** the failed pod.
  
  If your Pod's container process exits due to error, the Pod will be marked with `Status: Failed`
  
  But you can still debug the failed pod by attaching an Ephemeral container: <https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container>
  
  **Note:** Ephemeral containers are available as K8s alpha feature only from v1.16
  
  > **Comments:**
  > **username_3**: If you're using Docker Desktop as your local Kubernetes cluster, you can set the flag by modifying the kubeadm manifest files, as [seen here](https://stackoverflow.com/a/68971526/2441655).  
  
  ---
  
  ### Answer by username_0 on 2021-12-27. Score: 4
  
  I want to add a quick and dirty solution to this. I often add `sleep 600` to the end of a command that's failing unexpectedly so that I can `exec` in and poke around to see what happened. Yaml example (note: `- >-` enables multi-line concatenation, just a convenience):
  
  ```
          command: ["bash", "-c"]
          args:
            - >-
              python myscript.py; sleep 600;
  
  ```
  
  With that said, username_2's answer is better, this is just a simple solution that doesn't follow best practices. I encourage you **not** to use `sleep` or `sleep infinity`, because it's very easy to forget that your pod is running and holding onto resources indefinitely.
  
  > **Comments:**
  > **username_1**: This is the better solution. The above is just the usual rubbish about getting Kubernetes unhelpful status messages  
  
  ---
  
  