Latest update broke composer?

[mlantz7]

Hi there,

It seems something changed over the weekend that broke the package. It appears that "composer install" no longer runs automatically in the container, which broke our deployment process.

Any idea?

[mlantz7]

I think there are now some other issues as well...

I see crontab is working, but now I am seeing this in the logs:

PHP Warning:  PHP Startup: session.configuration 'session.sid_length' must be between 22 and 256. in Unknown on line 0
PHP Warning:  PHP Startup: session.configuration 'session.sid_bits_per_character' must be between 4 and 6. in Unknown on line 0
PHP Fatal error:  Allowed memory size of 2097152 bytes exhausted (tried to allocate 20480 bytes) in /srv/www/vendor/google/apiclient/src/Collection.php on line 97

I do use set some PHP_ env variables in the Dockerfile, and I do see that the values I set for them are correct when running php-envvars. But maybe they are not properly being set in PHP?

I no longer see the zz-generated-settings.conf file in either of the PHP config folders (php/conf.d/ and php-fpm.d/)

NOTE: I rebuilt the container (no changes) and the "zz-generated-settings" files showed up this time, but the errors/warnings persist.

[shinsenter]

@mlantz7

I’m very sorry for the issues you are experiencing. I will check the information you have provided and fix it soon, but could you let me know which Docker images you are using?

[mlantz7]

7.4-fpm-apache

Also, cron is giving me these errors every time it runs in syslogd/errors/current:

authpriv.err: Jul 29 17:09:01 CROND[13464]: pam_env(cron:session): Unable to open env file: /etc/default/locale: No such file or directory

This is my Dockerfile as of now:

FROM shinsenter/php:7.4-fpm-apache

# Install useful / needed packages
RUN apt-get update && apt-get install -y jq nano

# Add needed PHP extensions
RUN phpaddmod bz2 gmp mcrypt sockets

# Control your timezone
ENV TZ="America/Chicago"

# sets GID and UID (set to 33 for migrating from old prod server)
ENV APP_UID=33
ENV APP_GID=33

# Set needed paths for app
ENV APP_PATH="/srv/www"
ENV DOCUMENT_ROOT="/public_html"

# Disable composer install in package (handled in app init)
ENV DISABLE_AUTORUN_COMPOSER_INSTALL=1

# Setup crontab
ARG ENABLE_CRONTAB
ENV ENABLE_CRONTAB=${ENABLE_CRONTAB:-0}

# Set some PHP variables
ENV ALLOW_RUNTIME_PHP_ENVVARS=1

ENV PHP_SESSION_SERIALIZE_HANDLER="php"
ENV PHP_SESSION_SID_LENGTH="26"
ENV PHP_SESSION_SID_BITS_PER_CHARACTER="5"
ENV PHP_SESSION_GC_PROBABILITY=0
ENV PHP_OPCACHE_ENABLE_CLI=0

# Add startup file
ADD ./deploy/config/00-init /startup/00-init
RUN chmod +x /startup/00-init

# Add crontab
ADD ./deploy/config/app-crontab /etc/crontab.d/crontab
RUN chmod 644 /etc/crontab.d/crontab

# Copy source to the right place and setup proper ownership
COPY --chown=www-data:www-data . /srv/www/

WORKDIR $APP_PATH

Today I added the DISABLE_AUTORUN_COMPOSER_INSTALL and ALLOW_RUNTIME_PHP_ENVVARS to overcome some of the issues I was having. I now run "composer install" in my startup script (00-init).

When we pass in ENABLE_CRONTAB argument with 1, the crontab does get setup, as mentioned above. But it now gives the errors mentioned.

But yeah this is causing all kinds of issues for us today. I really wish there was a way to ensure new versions don't automatically break our deployments with versioning of some sort.

[mlantz7]

So it looks like /etc/default/locale is currently misnamed as /etc/default/localenv, which is causing the above problem. That also is likely causing the other issues with PHP vars not being set right huh?

[shinsenter]

@mlantz7

Thank you very much for the in-depth investigations. I apologize for the recent typo I made in /etc/default/locale. I will promptly correct it and rebuild all the Docker images as soon as possible, though it will take a few hours.

In the meantime, please try using other tags from the repo below to access previous builds of the shinsenter/php:7.4-fpm-apache.
https://hub.docker.com/r/shinsenter/php-archives/tags?name=7.4-fpm-apache

I hope this will help you get a stable build for production.

[mlantz7]

No worries. Stuff happens.

So just for clarity, are there 2 issues to resolve?

1. Composer install not running when it should
2. /etc/default/locale typo?

I am guessing (2) will fix other related issues other than cron, like the PHP vars not being properly set? I guess my use of ALLOW_RUNTIME_PHP_ENVVARS fixed it in some partial way, but should not be necessary if we are not trying to change those vars from within the container right?

--

And thanks for the tag info - I was not aware you had implemented that. It is very helpful - although then I will have to keep an closer eye out for bug fixes and such. :)

It would be pretty cool if there was somehow a more "stable" release channel, or major versions, etc...

Like I noticed the last "tagged" release was 5.0.3 back on March 12, which confused me a bit at first, because it made me think there were no changes and something else had went wrong. Then I checked in Docker Hub and saw the release several hours earlier.

[shinsenter]

@mlantz7

Based on my current understanding, I believe the typo in /etc/default/locale only affects certain Debian programs. The /etc/default/locale file contains a copy of the environment variables when the container is started to ensure that other programs within the container share the same set of environment variables related to PHP settings.

When running commands in the Dockerfile, since this file and other PHP dynamic config files are not yet created, PHP and other programs will essentially load the default settings. Therefore, fixing item number 2 might not resolve the composer error when it fails to run in the Dockerfile during your container builds (I need more error logs for deeper investigation).

However, I believe that correcting the typo in /etc/default/locale will fix the crontab errors.

[shinsenter]

@mlantz7

The release versions on this GitHub repository don't guarantee that Docker images built from the same source code will always be identical.

This is because my Docker images are built on PHP base images, meaning that PHP binaries, Debian/Alpine packages, Composer versions, etc. can change with each build. I've mentioned that I build my Docker images daily to include the latest security patches and software updates.

https://github.com/shinsenter/php/blob/5.x/README.md#stable-image-tags

We build new Docker images daily to ensure they stay up-to-date with the latest upstream updates for PHP, base OS, Composer, etc. The images in this repo are regularly updated under the same tag names.

For stable versions you can depend on in production, we also apply version tags on another repository.

👉🏻 View Stable Tags: https://hub.docker.com/r/shinsenter/php-archives/tags
This way, you get frequently updated images under static tags, providing both the latest code and production stability.

This means building your containers using any tags on the main Docker Hub repository might suddenly stop working one day. This issue is similar to using any other Docker image with the "latest" tag. To mitigate this, I've created separate archives for my Docker images based on their build date. You can consider the images on the main Docker Hub repository always "beta".

---

But above all, I haven't found a more optimal and user-friendly solution yet. If you have any good ideas, please let me know so we can discuss them further.

[shinsenter]

@mlantz7
The docker images for shinsenter/php:7.4-fpm-apache have been updated.

https://hub.docker.com/r/shinsenter/php-archives/tags?page=&page_size=&ordering=&name=20240730-7.4-fpm-apache

Could you please help me check again to see if your issue has been resolved?

[mlantz7]

So the locale file is now correct and is working fine. However, "composer install" still does not happen.

[shinsenter]

@mlantz7
When you run composer install, are there any specific error messages? Or any indications that it did not run completely?

[mlantz7]

Sorry, maybe the issue is unclear.

I can run composer install manually and there is no problem. In fact, that is what I had to change to once the normal functionality broke. Now I run it as part of my init processes.

The issue is that it used to run on its own automatically (before I added the DISABLE_AUTORUN_COMPOSER_INSTALL parameter). When I removed the parameter and tested again today, it did not run automatically as it used to.

Hopefully that makes things more clear.

[shinsenter]

@mlantz7

Sorry to keep you waiting, but can I ask you to test composer install again with the latest docker images? I hope this can solve your problem.

[shinsenter]

I will close this issue due to no updates. If you have any other concerns, please feel free to create a new issue.