Give better error code when shell not available so `fly intercept` can default to /bin/sh
Closed this issue · 5 comments
Todos
Please try the following before submitting the issue:
- Upgrade Concourse if you are observing a failure in a test (been a longstanding issue)
- [n/a] Use latest BOSH stemcell if the problem occurred in a BOSH VM
Description
When I complain to the Concourse team that fly intercept fails with an unhelpful message when my underlying container image doesn't have /bin/bash, they respond weakly, say it's a garden issue, and the issue stays open for a while. I was expecting Suraci to complain more, but he wasn't.
When I start a container with /bin/bash as the command to run, but it is not available, I get a somewhat uninformative error code. I would like a better exit code / message so that I can try another shell.
Logging and/or test output
Sorry, no logs
Steps to reproduce
fly execute -c task_that_runs_on_busybox.yml
fly intercept -b <number of build from above>
--> observe error
fly intercept -b <number of build from above> /bin/sh
--> you're in a shell on the container
Hi there!
We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.
The current status is as follows:
- #128380433 Give better error code when shell not available so
fly interceptcan default to /bin/sh
This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.
When I complain to the Concourse team that fly intercept fails with an unhelpful message when my underlying container image doesn't have /bin/bash, they respond weakly, say it's a garden issue, and the issue stays open for a while. I was expecting Suraci to complain more, but he wasn't.
That seems a bit unfair. We've had meetings about this and bring it up in Slack whenever it comes up again. At the moment it's in the icebox, and we agreed on an approach a while ago. In the meantime we've added bash to our resources so the issue is much less likely to come up. This was done a while ago, but in principle the underlying problem is still there for whatever images don't have bash, so we haven't closed the issue.
It's not on me to prioritize other teams' work; there are simply more important things to do, both in Concourse and in Garden. A PR would go a long way.
Hi @cjcjameson - just to add to what @vito says above, although this isn't currently our top priority (we're a small team and our current energy is focused on security and performance work) I hear you that it's a very useful feature for the concourse use case.
We've already made changes to start enabling this in garden-runc which mean that in recent versions of garden-runc when the process does not exist the failure happens immediately on the garden.Run call rather than the spawned process returning an error code.
The story to complete this work and use a specific error code for this case is here. I just scheduled it so it's now in the backlog and you can watch our progress on getting to it in tracker. As @vito says above, we'd be more than happy to accept a PR if you want to speed up progress on this issue.
Thanks!
Yep, sorry for being mean and insensitive. I hear y'all, and probably good to deprioritize it.
no worries!
On Wed, Aug 17, 2016, 12:57 PM C.J. Jameson notifications@github.com
wrote:
Yep, sorry for being mean and insensitive. I hear y'all, and probably good
to deprioritize it.—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
#49 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAHWI53skjtWTVYSJclcDKJZx89oTqEks5qg2fHgaJpZM4Jk6OW
.