Error response from daemon: OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown
I have this lando service set up to run oxigraph
name: webgrud
services:
oxigraph:
api: 3
type: lando
entrypoint: /usr/local/bin/oxigraph
app_mount: false
scanner: false
ssl: true
services:
image: ghcr.io/oxigraph/oxigraph:0.4.0-rc.1
user: root
command: serve --location /data --bind 0.0.0.0:7878
ports:
- 7878
It works fine but lando start --debug actually exists with code 17 and in the log I get
webgrud process pid9 running /Users/tplus/.lando/bin/docker-compose-v2.24.6 exec oxigraph /bin/sh mkdir -p /certs && /helpers/refresh-certs.sh > /certs/refresh.log cstdio=inherit, silent=false, mode=spawn, detached=false +53ms
Error response from daemon: OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown
webgrud process pid9 finished with exit code 1 +94ms
Well, I suppose it does not work 100% because I cannot access that service over HTTPS.
That said, there is not change with ssl: false
@tpluscode if you start up the image (ghcr.io/oxigraph/oxigraph:0.4.0-rc.1) are you able to use /bin/sh within it?
Hm, docker run --entrypoint sh produces a similar error and I cannot attach terminal either
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "sh": executable file not found in $PATH: unknown.
@tpluscode yeah, played with the image a little but wasn't able to spin up something fast. Looks like earlier image versions might have sh, not sure if later versions are just plain missing it or have it in an unexpected location.
If you can get a working instance running without Lando, that should be enough to work back from; might be worth reaching out to the oxigraph project to see if they have a tutorial somewhere.
So what should happen in the rare occasion that there is no shell interpreter in an image?
Lando reports an issue which does not actually prevent the container from starting up and functioning.
It looks like the oxigraph images are based on Google's distroless images which only have a shell in their debug versions. You could try using the experimental l337 service(which may not work at all) to add a build layer to the image that copies busybox, which includes sh, from a debug version of the distroless image. This might roughly look like this:
name: webgrud
services:
oxigraph:
api: 4
type: l337
image: |
FROM ghcr.io/oxigraph/oxigraph:0.4.0-rc.1
COPY --from=gcr.io/distroless/cc-debian12:debug /busybox /busybox
SHELL ["/busybox/sh", "-c"]
I changed to l337 and it kinda worked. I had to remove app_mount and ssl properties and like that I actually gained little because I still have no SSL set up for that service. Is that supported by l337 services?
But my question is whether I really need that? Could lando simply ignore the error and continue? I mean, in a sense it does. The service runs fine, albeit without SSL. Surely, there are other images out there without shell and I expect lando would handle that more gracefully
l337 services should have SSL, but that may have been added in one of the 3.22-beta releases, so you may have to update Lando to take advantage.
For reference, the following gave me https urls while running Lando 3.22.0-beta7:
name: l337-ssl
services:
l337:
api: 4
type: l337
image: nginx:1.22.1
volumes:
- "./:/app"
- "./default.conf.template:/etc/nginx/templates/default.conf.template"
ports:
- "8888"
proxy:
l337:
- hostname: l337.lndo.site
port: 8888
I derived that from the proxy examples, which is a good reference on some of the newer Lando features: https://github.com/lando/core/blob/main/examples/proxy/.lando.yml