There is no stderr when running command with `oc debug node`. $ oc --config=/tmp/kubeconfig debug node/ip-10-0-136-98.us-west-1.compute.internal -- ls /dasda/asdas 2> /dev/null ls: cannot access /dasda/asdas: No such file or directory The error output shouldn't be visible when running commands as I do above.
Sorry for mistake in title (I edited it). Basically all output goes to `stdout` instead of having proper stdout/stderr streams. For example `oc exec` works properly.
opened this: https://github.com/openshift/oc/pull/277 for multiple oc debug bugs
With the latest oc client, still can reproduce the issue now: [root@dhcp-140-138 ~]# oc version -o yaml clientVersion: buildDate: "2020-02-20T18:20:55Z" compiler: gc gitCommit: b3a52aa6b7df6f5f8fe35afc6f5d9b5cd095a1ff gitTreeState: clean gitVersion: v4.5.0 goVersion: go1.13.4 major: "" minor: "" platform: linux/amd64 [root@dhcp-140-138 ~]# oc debug node/dyan-shared44-6t8l6-control-plane-0 -- ls /dasda/asdas 2> /dev/null ls: cannot access /dasda/asdas: No such file or directory
The error is this: 'error: non-zero exit code from debug container' and that is getting redirected to /dev/null. The output of the function k8s.io/kubectl/pkg/cmd/logs 'RunLogs()' is what is printing the pod logs to stdout (and that will never be an error, unless there was in error in retrieving the logs). Redirecting that RunLogs() output to stdErr is ugly (https://github.com/openshift/oc/pull/277#discussion_r374155699). I'll spend some time on this to see if there's an acceptable way of redirecting pod logs to stderr.
We do not have options to split logs coming from the server, thus this part is not going to be fixed. The issue was only about debug elements, not logs coming from containers. Moving back to qa.
The original issue in description is exactly about splitting stdout and stderr from commands. What does it mean "We do not have options to split"? It is technically impossible? That is surprising because we *do* split log from `oc exec`. I think splitting stdout and stderr is a normal feature all CLI users do expect. I am not arguing how easy it is provided existing code or priority of the work. Just seeing this issue entirely rejected is not right in my opinion.
Exec is using different logic from logs, streaming logs does not split the logs to stdout and stderr.
I feel there is some confusion here. This bug is about `oc debug`, not `oc logs` and I think expectations and use cases are vastly different between the two commands - `oc debug node` is similar to `oc exec` (one is for pods and he other for nodes). While `oc logs` is just reading a log file and I agree that I've never seen logs split into stdin/stderr. While everything involving execution of random cli commands has ability to split. Even on Windows.
This is the bit that cannot be sent to stdErr: https://github.com/openshift/oc/blob/master/pkg/cli/debug/debug.go#L962-#L974 `oc debug` creates a pod from which it runs whatever the provided debug cmd. The logs from that pod are returned as part of the command, but regardless of whether the cmd in the debug pod failed or succeeded, the pod logs are returned as stdOut. We did recently improve `oc debug` to return an error if/when the command in the debug pod fails (like `oc debug node/ip-blah -- ls /foo` will now return an error and a msg to stdErr, rather than exit 0).
Confirmed with latest oc client, the issue can't reproduced : [root@localhost ~]# oc debug node/ip-xxxxxx.compute.internal -- ls /dasda/asdas 2> /dev/null ls: cannot access /dasda/asdas: No such file or directory [root@localhost ~]# echo "$?" 1 [root@localhost ~]# oc version -o yaml clientVersion: buildDate: "2020-02-28T04:39:11Z" compiler: gc gitCommit: 79259a8f76edb4bb0e3ca96784b13949a8682d94 gitTreeState: clean gitVersion: 4.5.0-202002280431-79259a8 goVersion: go1.13.4 major: "" minor: "" platform: linux/amd64
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-2020:2409