Hello,
What command are you running ?
Is the application container you are trying to connect to running ?
Does the error happen if you try connecting a second time ?
No, I’m not. Problems seems to be coincident with another issue that I have contacted balena support about - where the device does not update to the target release. It’s still not clear what causes that but perhaps that effort will shed some light on this.
Does this happen on other OS versions or is it specific to the OS 2.32.0+rev1 version you are using. Could you also supply the CLI version you are using. One other clarification that would help is how regularly this happens. Does it occur 100% of the time with the CLI, or is it say 1 in 5 times, I think that will help us narrow things down.
Doesn’t happen all the time - has happened twice and both times the supervisor was jammed (hence not updating). What’s curious is that I can connect from the dashboard. Running 11.19.1
I’ve only experienced it with a couple devices so far. Have since learned that it may be related to supervisor getting jammed as a result of a bug in 2.32, apparently fixed in 2.45. What is confusing to me is that if the supervisor is jammed, then shouldn’t the connection fail from either dashboard or CLI? I have only experienced it as failing from the CLI in these cases.
The CLI makes a call to the supervisor API to get the container ID which you are trying to SSH into. The web dashboard does not require that API call so it works even if the supervisor is not running. We are discussing internally if we can implement the same approach on the CLI to remove the supervisor requirement.
@0xff, for your information, the balena CLI’s dependency on the supervisor was removed in CLI v13.3.0 or later, such that balena ssh should now succeed even if the supervisor is not running on the device. This also brings the CLI’s ssh behaviour in line with the web dashboard,