Description of problem: Pods are stuck in terminating state, pod logs show the one line error "json: cannot unmarshal array into Go value of type types.ContainerJSON" ~~~ #oc logs <podname> json: cannot unmarshal array into Go value of type types.ContainerJSON ~~~ #oc delete pod podname-44-build --grace-period=0 --force The above command says deleted but pod still exists in the Terminating state. Version-Release number of selected component (if applicable): OCP v3.7.52 Actual results: Not able to delete the pod Expected results: Should get delete the pod Additional info:
Checked on # oc version oc v3.7.60 kubernetes v1.7.6+a08f5eeb62 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://ip-172-18-9-51.ec2.internal:8443 openshift v3.7.60 kubernetes v1.7.6+a08f5eeb62 Now the message from oc logs for terminating pods is: # oc logs -f httpd-example-1-vw576 Error: No such container: 41627b7750be4a50b96afa93f29143747812598ffe470d59a4f36cbf1764775d But I expect the following message: container 41627b7750be4a50b96afa93f29143747812598ffe470d59a4f36cbf1764775d in pod httpd-example-1-vw576 is terminated
The error message that you got is appropriate in some cases. You should only expect to see the "container ... in pod ... is terminated" message when the pod was trying to start a new container while terminating, but hadn't made it far enough along to get a container ID for the new container. In cases where the container ID is known, we try to fetch its logs from the runtime (i.e. Docker) and if it has completely removed the container, we'd expect an error like the one you got. In my opinion, the new behavior observed is acceptable and should not be considered a bug.
Move to verified according to https://bugzilla.redhat.com/show_bug.cgi?id=1598090#c7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2547