If I run 'while true; do echo 1; done' command in shell, the browser will be stucked.

When I leave a shell and refresh, the dashboard crashes with the following error:

Is this related to the Some solution to respawn if the user exits the shell (?) point ?

I assume the problem is that it tries to read data from a closed socket.

I assume the problem is that it tries to read data from a closed socket.

I think you are right. We probably should have some button to open terminal and when session is terminated or there is a timeout automatically close it. Refreshing the page would close the session and open a new one.

FYI exec/attach should work w/ kubectl proxy after kubernetes/kubernetes#49534 gets merged.

@ianlewis Great.

@maciaszczykm Yah. Not sure if updating to use WebSockets is in scope of this issue or not though.

A couple more issues for the list:

1. Most of my pods are multi container. I need a way to specify which container to exec into.
2. Quite a few containers these days don't have /bin/bash but only /bin/sh. Being able to specify would let it work in many more cases.

1. There is a combobox on exec page where you can select a container.
2. If /bin/bash is not found it falls back to /bin/sh already. If both are not present you'll get an error.

@floreks the second part never works, when it fails back to /bin/sh the console closes right after shell started.

If /bin/bash present, everything works well!

This is related to incorrect session handling. Exec is in early stage and we are aware that there are some issues that make exec unusable for now. We are working on fixing them. It will be more stable in 1.7 release.

Just FYI as this is relevant to this thread. I've started seeing the following message after upgrading dashboard to 1.7: unable to upgrade connection: you must specify at least 1 of stdin, stdout, stderr. This happens even when I give dashbord admin privileges (i.e. skip auth).

Rolling back to 1.6.3 makes it possible again to execute bash while getting "connection closed" for shell-only pods.

@maciaszczykm do want me to open a new issue for this? Or is it fine to collect such glitches under this umbrella issue?

@kachkaev It is fine. Security was out piority 0 issue for 1.7 release, but now we should be able to find some time for issues like that.

I am using the kops version of the dashboard in one of our environments and have taken this yaml: https://github.com/kubernetes/kops/blob/master/addons/kubernetes-dashboard/v1.7.0.yaml, just updated the dashboard image to 1.7.1 and still seeing the 'Connection closed' issue if the pod does not have bash. I have confirmed in the About section that it really is 1.7.1 and interestingly enough in our other cluster where we are using the recommended yaml from the repo here it all works fine.

They differ a bit :) Very important part is missing in your yaml file.

        volumeMounts:
        - name: kubernetes-dashboard-certs
          mountPath: /certs
          readOnly: true
          # Create on-disk volume to store exec logs
        - mountPath: /tmp
          name: tmp-volume
        livenessProbe:
          httpGet:
            scheme: HTTPS
            path: /
            port: 8443
          initialDelaySeconds: 30
          timeoutSeconds: 30
      volumes:
      - name: kubernetes-dashboard-certs
        secret:
          secretName: kubernetes-dashboard-certs
      - name: tmp-volume
        emptyDir: {}

@floreks Thanks for that snippet - the kops deployment is also just accessible via https and is using its own cert. It even provides a shortcut url https://api.cluster-name.company.com/ui, which then using 1.7.1 with this snippet (and the new init containers) breaks, returning:

Error: 'malformed HTTP response "\x15\x03\x01\x00\x02\x02"'
Trying to reach: 'http://some-ip:8443/'

Should this then be a new issue here, or is that more kops responsibility?

/ui redirect has not been updated yet and points to wrong scheme (http instead of https). Check links provided in README or Accessing Guide on our wiki pages. There are correct links provided.

@Globegitter You can check current status at #2395 and in referenced issues.

@floreks Is there a ticket or line-item tracking this: "when it fails back to /bin/sh the console closes right after shell started."

I'm still experiencing the crash every time with gcr.io/google_containers/kubernetes-dashboard-amd64:v1.8.0

it is still crashes.
image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.8.2

2018/01/24 10:26:41 [2018-01-24T10:26:41Z] Outcoming response to 100.96.1.1:38112 with 200 status code
E0124 10:26:41.855858       1 v2.go:105] sockjs: session not in open state
E0124 10:26:41.855858       1 v2.go:105] sockjs: session not in open state
log: exiting because of error: log: cannot create log: open /tmp/dashboard.kubernetes-dashboard-7b4745d8fb-x2vsz.unknownuser.log.ERROR.20180124-102641.1: no such file or directory

If you have used some custom yaml to deploy it then it might. We are explicitly creating /tmp dir inside the container to avoid this error in our yaml files. https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml#L131

If you have used some custom yaml to deploy it then it might. We are explicitly creating /tmp dir inside the container to avoid this error in our yaml files. https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml#L131

Thank you it works for me! Crash does not happend!

@floreks Currently , the dashboard version is v1.7.1 in my environment, I found that if the command '/bin/bash' does not exists in another container, I can't login into that container from dashboard.
An error output as follow:

But the /bin/sh exsits in that container, why dose the dashboard not use /bin/sh to login into the container？
Is there a dashboard image supports both /bin/bash and /bin/sh currently？