Red Hat Bugzilla – Bug 1345847
'oc debug' raise error and quit before debugging pod is started
Last modified: 2017-03-08 13:26 EST
Description of problem: Sometimes oc debug raise error and quit debugging process before debugging pod is up Version-Release number of selected component (if applicable): oc v3.2.1.1-1-g33fa4ea kubernetes v1.2.0-36-g4a3f9c5 How reproducible: Sometimes Steps to Reproduce: 1. Create test app $ oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-stibuild.json 2. Wait for DC 'database' completed and pod running $ oc get pods NAME READY STATUS RESTARTS AGE database-1-jgc6f 1/1 Running 0 3m 3. Debug DC 'database' [yapei@dhcp-128-14 Openshift_test]$ oc debug dc/database --loglevel 6 -- /bin/env I0613 17:45:47.456637 8744 loader.go:242] Config loaded from file /home/yapei/.kube/config I0613 17:45:48.895593 8744 round_trippers.go:286] GET https://master:port/oapi 200 OK in 1437 milliseconds <...snip...> Debugging with pod/database-debug, original command: <image entrypoint> I0613 17:45:51.882029 8744 round_trippers.go:286] POST https://master:port/api/v1/namespaces/yapei-test-2/pods 201 Created in 321 milliseconds I0613 17:45:51.883205 8744 debug.go:413] Created attach arguments: cmd.AttachOptions{Namespace:"", PodName:"", ContainerName:"ruby-helloworld-database", Stdin:false, TTY:false, CommandName:"", InterruptParent:(*interrupt.Handler)(0xc20858b050), In:(*os.File)(0xc20802c000), Out:(*os.File)(0xc20802c008), Err:(*os.File)(0xc20802c010), Pod:(*api.Pod)(0xc2083ef400), Attach:(*cmd.DefaultRemoteAttach)(0x2ca2340), Client:(*unversioned.Client)(0xc2083a7650), Config:(*restclient.Config)(0xc20806a000)} I0613 17:45:52.175995 8744 round_trippers.go:286] GET https://master:port/api/v1/watch/namespaces/yapei-test-2/pods?fieldSelector=metadata.name%3Ddatabase-debug&resourceVersion=51507 200 OK in 292 milliseconds Waiting for pod to start ... I0613 17:46:23.619710 8744 round_trippers.go:286] GET https://master:port/api 200 OK in 1port milliseconds I0613 17:46:23.917597 8744 round_trippers.go:286] GET https://master:port/apis 200 OK in 297 milliseconds I0613 17:46:24.213321 8744 round_trippers.go:286] GET https://master:port/api 200 OK in 295 milliseconds I0613 17:46:24.509268 8744 round_trippers.go:286] GET https://master:port/apis 200 OK in 295 milliseconds I0613 17:46:24.847200 8744 round_trippers.go:286] GET https://master:port/api/v1/namespaces/yapei-test-2/pods/database-debug/log?container=ruby-helloworld-database&follow=true 400 Bad Request in 337 milliseconds Removing debug pod ... I0613 17:46:25.200642 8744 round_trippers.go:286] DELETE https://master:port/api/v1/namespaces/yapei-test-2/pods/database-debug 200 OK in 352 milliseconds I0613 17:46:25.201492 8744 helpers.go:172] server response object: [{ "metadata": {}, "status": "Failure", "message": "container \"ruby-helloworld-database\" in pod \"database-debug\" is waiting to start: ContainerCreating", "reason": "BadRequest", "code": 400 }] F0613 17:46:25.201525 8744 helpers.go:107] Error from server: container "ruby-helloworld-database" in pod "database-debug" is waiting to start: ContainerCreating Actual results: 2. Before debugging pod is started, 'oc debug' raise error and quit Expected results: 2. Should wait for the container 'ruby-helloworld-database' to started Or if the container failed to started in a planned duration, it's better to give timeout error message rather than << container "ruby-helloworld-database" in pod "database-debug" is waiting to start: ContainerCreating >> Additional info:
Created attachment 1167414 [details] WholeError
Clayton: is this https://github.com/openshift/origin/pull/9867 ?
Yes it is.
Checked against oc v3.2.1.13(to make sure fix is back port in 3.2 too) & oc v3.3.0.18 With the same steps, "oc debug dc/database --loglevel 6 -- /bin/env" could start debug pod successfully and return correct response
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-2016:1933