Regarding ENTRYPOINT Launcher

[SAURABH110894]

I'm Facing Some Issue During CNB Image Launch.

Case

podman run it --name=demo --entrypoint launcher demo_image "sh /layers/demo/mx-demo/scripts/db-startup.sh && /cnb/process/web"

Above Command Run the Image and if we do Inspect on this Container.

saurabh@saurabhpal:~$ podman inspect aa6a49d33c37
[
{
"Id": "aa6a49d33c37c255c423392b892c393999c42e6ff1ebee12dfc8939ffd742a31",
"Created": "2023-03-24T09:49:45.1066431+05:30",
"Path": "launcher",
"Args": [
"sh /layers/demo/mx-demo/scripts/db-startup.sh \u0026\u0026 /cnb/process/web"
],

Here if See Path is launcher.

And if same things I'm trying to do via Dockerfile.

FROM demo_image
ENTRYPOINT launcher /layers/demo/mx-demo/scripts/db-startup.sh && /cnb/process/web

saurabh@saurabhpal:~/test$ podman inspect 169bf306e77f7b41157ce07f181ce4150c8779dfe81ff5548f65c644799578bf
[
{
"Id": "169bf306e77f7b41157ce07f181ce4150c8779dfe81ff5548f65c644799578bf",
"Created": "2023-03-24T09:54:08.0644879+05:30",
"Path": "/bin/sh",
"Args": [
"-c",
"launcher /layers/demo/mx-demo/scripts/db-startup.sh \u0026\u0026 /cnb/process/web"

The Path is /bin/sh but it should be launcher.

The Path is different in both the case.

why I want this launcher because we want to inherit all CNB Features.

[SAURABH110894]

@natalieparellano @sclevine Could you please help for this case

[SAURABH110894]

it worked using below Case.

FROM demo_image
ENTRYPOINT ["launcher", "/layers/demo/mx-demo/scripts/demo-startup.sh && /cnb/process/web"]

this is the way we should be doing, if we want to run a script prior to running the CNB logic to start the tomcat.

Looking for Advice this won't impact any CNB functionally

[natalieparellano]

@SAURABH110894 it's potentially worth noting that /cnb/process/web is a symlink to the launcher itself, with arg[0] telling the launcher which process to start. So in the workflow above you are actually calling the launcher twice. I don't think there is any harm in that though, if it's working for you, and avoids the need to re-specify any arguments that may be passed to the web process.

Possibly of interest is the discussion here around the potential for some sort of aggregation of buildpack-provided processes, in particular:

Possibly off-topic, but a challenge that we have with a buildpack like the Paketo tini buildpack is that it cannot be self-contained. It can be used to install the tini binary, but what you really want is for some other buildpack to emit the process types and for the tini buildpack to run and wrap those process types with tini + <whatever the other buildpack set>. I'm under the impression that is not possible (correct me if I'm wrong), which I think makes having an elegant solution at the buildpack level difficult.

This isn't currently part of the CNB spec, but perhaps your use case is further evidence that we need something like this. cc also @dmikusa as the original commenter, who may have further thoughts here.

[natalieparellano]

@SAURABH110894 I'll close this issue for now, but please feel free to circle back if you need further assistance.