No logs from scripts when using custom docker image

[Kamil]

Hi I'm having an issue when logs are not showing for all scripts within the step that uses custom docker image.

The custom image is created from official php-fpm:7.2 docker image. When running the official image script output is visible. I've reviewed the Dockerfile, but I can't see a reason why it would change behaviour.

Any ideas where I can look to find the source of the problem?

[Kamil · Accepted solution]

The source of my problems was the fact that the newly created user didn't have write permissions in his home folder.

This solves all of my problems.

[ktomk]

Thanks for sharing the solution. I didn't thought about that.

[Kamil]

This is how it looks in the pipeline console.
This pipeline contained simple step: 'echo test'.

I can tell that all scripts are run as artifacts are created as well it can proceed to the next step

[ktomk]

Welcome to the Atlassian Community.

On first glance at least for me this is not so easy to answer.

Maybe you can share the complete name of the container image? Just because php-fpm:7.2 is not found by the Atlassian Bitbucket Cloud Pipelines Plugin so what you write about I can not easily reproduce; gives the following error:

rpc error: code = Unknown desc = failed to resolve image "docker.io/library/php-fpm:7.2": no available registry endpoint: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

Sharing all the relevant parts of your bitbucket-pipelines.yml might also not be a bad idea next to your screenshot.

Regarding that screenshot you posted:

When you extend the "Build setup" section (and also the "Build teardown" section), what does it show?

I ask because I had a similar issue (like "no logs from script") and it showed an error message therein. Compare with the screenshot / infos in the question Pipeline Build Setup: /bin/sh: /usr/bin/mkfifo: not found.

It was with a different image (not ???/php-fpm:7.2 but docker.io/busybox) and I could resolve the issue with a little modification of the image. Your mileage may vary.

[Kamil]

Hi. Thanks for your response and sorry for not enough information included in my post.

I've put mistake in docker image I referenced its: 'php:7.2-fpm'. From that image I create another one called 'kingfisherdirect/magento2-php:2', which Dockerfile you can find here: https://bitbucket.org/kingfisherdirect/docker-magento2-php/src/v2/Dockerfile.

For this issue I created a small public repository which shows issue without anything else.

https://bitbucket.org/kamil-kingfisher/docker-pipeline-test/addon/pipelines/home#!/results/1/steps/%7B8162f12c-ebed-41ba-bdc5-f18ac2b0224b%7D

[ktomk]

Sorry for not being able to reply earlier. I couldn't find anything specific for which I could say this is it.

What caught my attention is that in the entry-point of your custom image, `$@` is not quoted with `exec` at the end:

exec $@

 I would change that to quoted:

exec "$@"

Maybe it helps. I was looking into the entry-point related parts of the Dockerfiles first.

[Kamil]

I've updated entry-point to wrap the exec argument, but that didn't change anything in pipeline output.

[Kamil]

Isn't the entrypoint ignored by Pipelines, so it can run scripts from pipeline configuration?

[ktomk]

This I think is a very good question. I tried to find this out in more detail and the examples you provided are a great base to look into this, but so far I was not able to grasp some solid understanding here.

As Bitbucket Pipelines (BBPL) kinda hides this it requires some sort of reverse engineering.

From earlier tests I'm a bit under the impression that BBPL does not set the entry-point explicitly to `bin/sh`. IIRC in my pipelines utility which runs pipelines locally it's done that way and it works pretty stable. But the reporting is also different, so even if a counter-test against the pipelines command-line utility does actually work, this could not fully answer your question (but shed some insights I guess). As you're using PHP anyway, you might want to take a peek if it's not to the benefit of your workflow anyway. Just saying.

Please keep the examples online, I'd really like to tinker with them when I find the time.

---

/// I've updated entry-point to wrap the exec argument, but that didn't change anything in pipeline output.

Yes, this was merely a quick shot. I was coming from comparing the differences to the base image from official PHP docker images. Maybe there are some more differences I was just not able to spot right way?

---

So to answer on your question to what I know:

If Bitbucket Pipelines (BBPL) uses Docker - which I think we can assume fine - unless the entry-point is specified when running a container (`docker run` command w/ `--entry-point` argument) specifically (which I don't know if this happens in BBPL, and from some tests some weeks ago I tend to say it happens not and I start to remotely sense some reasoning why not), the entrypoint set in the image is not generally ignored in BBPL.

My current understanding is that for a pipeline step, BBPL creates a volume (container) first, with the git checkout and then runs the pipeline container (`docker run`) executing the step script with the `/bin/sh` command (`/bin/sh` is sort-of the base-line of anything docker). This *should* be safe for most of all containers out there (the Linux* containers, ignoring Windows here).

In the end I think any of the options of how to safeguard from container configuration for pipelines execution (here: BBPL), it's that there can always be leak from the container configuration to the pipelines execution. This is why I find such a case like yours quite interesting.

As already written earlier, the only case I ran about something similar before was with the path of the mkfifo command in the busybox image.

Your case is different as there is no error message but somehow different, the output is either not going towards the host (standard streams are either muted or going into a file, like a log file as it's a PHP-FPM server container maybe - all wild guesses here) or for some other reason the fifo that the web-console is getting data from is producing any data (e.g. there _is_ no data or redirected into a file/null device or similar).

Maybe you have got some more ideas or questions so it's easier to get a better understanding.

[Kamil]

I've managed to produce smallest Dockerfile that causes pipeline to not display any output

```

FROM php:7.3-fpm

RUN useradd -u 1000 -d /var/www app

```

[Kamil]

The source of my problems was the fact that **the newly created user didn't have write permissions in his home folder**.

This solves all of my problems.