Improve behavior when working with barebone containers (distroless, FROM scratch...)

[jpetazzo]

Two examples.

1. Select a pod with a container that doesn't have a shell available. Hit s. An error message quickly flashes on the screen (saying "sh" executable not found) but it disappears instantly.

Suggestion: detect that an error happened when trying to execute the shell process, and display the error (maybe in a modal popup; I'm not familiar with sofka yet to know if there is a convention to report that kind of problem to the user).

Further suggestion: the error message could suggest other ways (debug container, or perhaps even adding a volume to the container, with a shell in the volume - that's the trick I teach to my students in my k8s class, but I don't know if sofka wants to go that far :))

2. Select a PVC mounted in a container that doesn't have basic tools available (thus preventing the PVC explorer from listing files). Hit x. The PVC explorer panel shows an error message.

Suggestion: detect that the error happened, and fallback to the other strategies used when no container mounts the PVC.

Why this matters: many folks use or build images based on full distros, with shells and other tools, and will never run into this issue. However, many security-conscious folks choose to reduce the vulnerability footprint in their image, using bases like distroless images, FROM scratch, or similar schemes that result in an absence of a shell or other basic tools in their image.

I didn't want to file this as a bug, because it doesn't cause sofka to crash, and arguably, an error message is shown; but in case 1, the message is displayed very briefly, and in case 2, sofka actually implements a workaround but doesn't trigger it.

[nklmilojevic]

Thanks, @jpetazzo, for the clear examples and suggestions. Both are useful improvements, and the disappearing shell error is a bug even though sofka does not crash.

I agree with the scope below. These recovery tools should be built in and available by default, without plugins or extra configuration. I opened two issues:

• fix: retain shell errors and offer built-in debug recovery #606: Keep shell errors visible and offer the existing debug-container workflow when a shell is missing. Show the image and require an explicit user action before creating the debug container.
• feat: offer PVC browsing recovery when container tools are missing #607: When PVC browsing fails because required tools are missing, try another running container that mounts the claim. If none works, offer a helper pod with the existing confirmation and guardrails.

The PVC fallback must account for volume access restrictions. An in-use ReadWriteOnce volume needs the helper on the consumer's node; an occupied ReadWriteOncePod claim cannot use a second pod. Permission and connection errors must remain distinct from missing-tool errors.

We will keep the original error available if recovery is blocked. Shell injection through an added volume is outside this first scope.

Thanks again for showing where the current workflow stops too soon.