Open mbrodala opened 4 years ago
Could it be that this is somehow related to startup speed?
Today I was able to reproduce this locally for the very first time. A composer install
failed since the zip
PHP extension was supposedly missing, even though it is mentioned in PHP_EXTENSIONS
. However, directly entering the container and running php -m
showed the zip
extension. And running composer install
again at this point worked just fine.
So is it possible that the PHP extension setup at runtime can fail or be slow?
This is weird. The main command is not supposed to start before the php configuration files have been written. So my first thought would be to exclude any idea of a race condition.
Is anyone else having the issue?
Also, @mbrodala, could you share your docker-compose / Dockerfile? Are you doing anything special like redefining the Entrypoint or mounting PHP configuration directories?
@mbrodala Can you reproduce this consistently on your local environment or did it happen only once?
We do not override the entrypoint and also do not mount any PHP configuration. We do everything through the environment variables provided by the images here.
I'll try to come up with a minimal example to show the issue.
Thanks! I'm linking to #201 too which might be related (not sure, but I'll need to check this)
I wasn't able to reliably reproduce this locally yet but can confirm that there's something fishy since I've prepended a plain php -m
before the Composer command and it shows that some PHP extensions could indeed not be loaded:
> build: @lint
> lint: php -m
PHP Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20170718/mysqli.so (/usr/lib/php/20170718/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20170718/mysqli.so.so (/usr/lib/php/20170718/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20170718/pdo_mysql.so (/usr/lib/php/20170718/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20170718/pdo_mysql.so.so (/usr/lib/php/20170718/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20170718/mysqli.so (/usr/lib/php/20170718/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20170718/mysqli.so.so (/usr/lib/php/20170718/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20170718/pdo_mysql.so (/usr/lib/php/20170718/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20170718/pdo_mysql.so.so (/usr/lib/php/20170718/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
[PHP Modules]
apcu
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
igbinary
json
libxml
mbstring
openssl
pcntl
pcre
PDO
Phar
posix
readline
redis
Reflection
session
shmop
SimpleXML
soap
sockets
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcache
> lint: @lint:php
> lint:php: parallel-lint --exclude bin --exclude vendor --exclude web/typo3 --exclude web/typo3temp .
PHP Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20170718/mysqli.so (/usr/lib/php/20170718/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20170718/mysqli.so.so (/usr/lib/php/20170718/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20170718/pdo_mysql.so (/usr/lib/php/20170718/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20170718/pdo_mysql.so.so (/usr/lib/php/20170718/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20170718/mysqli.so (/usr/lib/php/20170718/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20170718/mysqli.so.so (/usr/lib/php/20170718/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20170718/pdo_mysql.so (/usr/lib/php/20170718/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20170718/pdo_mysql.so.so (/usr/lib/php/20170718/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP 7.2.30 | 10 parallel jobs
............................................................ 60/118 (50 %)
....................................................Error in skip-linting.php process
Error output: PHP Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20170718/mysqli.so (/usr/lib/php/20170718/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20170718/mysqli.so.so (/usr/lib/php/20170718/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20170718/mysqli.so (/usr/lib/php/20170718/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20170718/mysqli.so.so (/usr/lib/php/20170718/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20170718/pdo_mysql.so (/usr/lib/php/20170718/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20170718/pdo_mysql.so.so (/usr/lib/php/20170718/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20170718/pdo_mysql.so (/usr/lib/php/20170718/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20170718/pdo_mysql.so.so (/usr/lib/php/20170718/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Script parallel-lint --exclude bin --exclude vendor --exclude web/typo3 --exclude web/typo3temp . handling the lint:php event returned with error code 254
Script @lint:php was called via lint
Script @lint was called via build
Interestingly gd
listed here is set by us in PHP_EXTENSIONS
...
Interesting. I ran into this: https://www.linuxquestions.org/questions/slackware-14/php-7-1-in-testing-%BB-unable-to-load-dynamic-library-mysqli-so-4175618544/
It might be related to the order the Mysql related extensions are loaded. Note to self: I'll have to check this out.
@moufmouf Where you already able to have a look at this? PHP extensions loaded in the wrong order would make more sense to me than the libraries missing in the filesystem ...
Very weird. Have a look at this file: https://github.com/thecodingmachine/docker-images-php/blob/v3/utils/setup_extensions.php#L56-L60
Here, I am making sure that the "mysqlnd" extensions is loaded if "mysqli" or "pdo_mysql' extensions are loaded. I am using the "phpenmod" command from Ubuntu to enable the module.
The "phpenmod" command should take care of the priority by prepending the "mysqlnd.ini" file with "10-" (while mysqli.ini is prepended with "20-") https://serverfault.com/a/1010514
When I run this command locally:
docker run --rm -e "PHP_EXTENSIONS=pdo_mysql" thecodingmachine/php:7.2-v3-cli ls /etc/php/7.2/cli/conf.d
I am seeing this output:
10-mysqlnd.ini
10-opcache.ini
10-pdo.ini
15-xml.ini
20-apcu.ini
20-calendar.ini
20-ctype.ini
20-curl.ini
20-dom.ini
20-exif.ini
20-fileinfo.ini
20-ftp.ini
20-gettext.ini
20-iconv.ini
20-igbinary.ini
20-json.ini
20-mbstring.ini
20-mysqli.ini
20-pdo_mysql.ini
20-phar.ini
20-posix.ini
20-readline.ini
20-redis.ini
20-shmop.ini
20-simplexml.ini
20-soap.ini
20-sockets.ini
20-sysvmsg.ini
20-sysvsem.ini
20-sysvshm.ini
20-tokenizer.ini
20-wddx.ini
20-xmlreader.ini
20-xmlwriter.ini
20-xsl.ini
20-zip.ini
generated_conf.ini
Since modules are loaded in alphabetical order, mysqlnd is loaded first. And of course, I am not getting any error.
Could you try running ls /etc/php/7.2/cli/conf.d
before composer? I'm ready to bet files are not sorted correctly. The question will then be: why?
Here's the output from various builds, unfortunately there is no pattern visible since technically all desired extensions seem to be loaded as requested:
As you can see the warnings also show up on successful runs but don't cause it to fail.
In both case, the 10-mysqlnd.ini
is not loaded which is strange, because it definitely should according to https://github.com/thecodingmachine/docker-images-php/blob/v3/utils/setup_extensions.php#L56-L60
The error is related, but it will be hard to solve if I can't reproduce it.
Could you share more about your setup? Are you running "composer" inside a "Dockerfile" or inside "docker-compose"? Any way you can send me a trimmed down version of those files that reproduce the issue?
Sorry for the delays, I am usually in a 2 week sprint with a 2 week break in between.
Our setup is spun up with Docker Compose and Composer is then executed via exec
. In any case I already noticed one possible issue: we basically do this:
docker-compose up -d
docker-compose exec app composer ...
With this there's at least some risk that not all services have fully started yet which we noticed in one project failing to connect to MySQL. I'm not sure if timing is also relevant for the PHP extensions/FPM startup.
I'll see if I can manage to get a reproducible setup. Again, this only occurs when running CI builds, never locally. This would support the timing issue theory since the same command runs a lot faster locally. (Both using SSD however.)
I think I am definitely onto something here: I'm currently trying to optimize our CI pipeline (GitLab) e.g. by splitting it into jobs. With this I now see the errors mentioned here in a project which was mostly unaffected as of now. This should mostly stem from the fact that most setup is performed only once and subsequent jobs are directly executed. So the time between environment startup for a job (docker-compose up -d
) and job execution (docker-compose exec
) is vastly reduced.
A job which runs functional tests against an actual MySQL database fails now:
Error: Call to undefined function Doctrine\DBAL\Driver\Mysqli\mysqli_init()
And:
PHPUnit\Framework\Exception: PHP Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20190902/mysqli.so (/usr/lib/php/20190902/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20190902/mysqli.so.so (/usr/lib/php/20190902/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
But a retry of this job interestingly leads to the last bunch of tests to succeed where I assume that the MySQL server finished its startup at this point. Before that it was very likely still starting and preparing the database:
Here's the current state with all logic in a single build job:
I know https://github.com/jwilder/dockerize which I could probably use to override/extend the entrypoint of the PHP image and properly wait for MySQL.
But I'm not sure what exactly is going on within the PHP image after container start to have PHP extensions missing up until a certain point. Adding a plain sleep 20
already helps to improve the situation ...
FYI: I added waiting for MySQL with these two simple changes:
Dockerfile
ARG DOCKERIZE_VERSION=v0.6.1
RUN curl -sfLO https://github.com/jwilder/dockerize/releases/download/${DOCKERIZE_VERSION}/dockerize-linux-amd64-${DOCKERIZE_VERSION}.tar.gz \
&& tar -C /usr/local/bin -xzvf dockerize-linux-amd64-${DOCKERIZE_VERSION}.tar.gz \
&& rm dockerize-linux-amd64-${DOCKERIZE_VERSION}.tar.gz
STARTUP_COMMAND_1: dockerize -wait tcp://mysql:3306
to our app service.(I tried overriding the ENTRYPOINT
but this led to weird sudo
errors.)
However, I still see failures due to mysqli_init()
being undefined due to mysqli
not being loaded properly.
@moufmouf Would you mind adding debugging output to all of your scripts so that a docker-compose logs
is able to display them?
My current suspicion is that Docker (Compose) launches your entrypoint script and happily returns from that. At this points commands could be exec
uted even before the entrypoint script finishes its startup procedure which includes PHP extension setup.
FYI: I added waiting for MySQL with these two simple changes
I suspect the error about the PHP Mysql extension is not related to the fact that MySQL listens to connections or not.
However, the idea of a race condition between the docker container starting and a "exec" performed on the docker container makes plenty of sense!
However, you mention you are using a Gitlab pipeline. This is weird to me because, in my understanding, Gitlab CI is not doing an "exec" but a "docker run". I'm using Gitlab myself and have never run into these problems. These could be related to the kind of Gitlab runner you are using however. Could you tell me which kind of Gitlab runner you are using?
Would you mind adding debugging output to all of your scripts so that a docker-compose logs is able to display them?
To be honest, I feel a bit reluctant about adding debug info to a container used by so many people. However, I'd be happy to help you adding the logs, rebuilding the container and pushing it on a registry (you can push it on your Gitlab registry) to test any changes!
FYI: I added waiting for MySQL with these two simple changes
I suspect the error about the PHP Mysql extension is not related to the fact that MySQL listens to connections or not.
Exactly, I just wanted to point out the coincidence of the timing issues here. :-)
However, you mention you are using a Gitlab pipeline. This is weird to me because, in my understanding, Gitlab CI is not doing an "exec" but a "docker run". I'm using Gitlab myself and have never run into these problems. These could be related to the kind of Gitlab runner you are using however. Could you tell me which kind of Gitlab runner you are using?
We are currently migrating from Shippable to GitLab where we went straight for the shell executor. This allows us to use docker-compose
the same way as locally without any workarounds. Basically docker-compose
is executed directly on the build node without any interference. On Shippable (where the same issue exists) we had to do some extra steps. Unfortunately we see the same race condition on GitLab as we saw on Shippable.
To be honest, I feel a bit reluctant about adding debug info to a container used by so many people.
And I understand that. But maybe some debug variants would be useful even for other people.
However, I'd be happy to help you adding the logs, rebuilding the container and pushing it on a registry (you can push it on your Gitlab registry) to test any changes!
I'll see if I can figure something out by overriding the entrypoint and scripts related to PHP extension management.
@moufmouf Could this be the issue?
When you load mysqli after mysqlnd, this solves the issue. BUT if you use phpenmod to enable the modules they enable in alphabetical order. mysqli is before mysqlnd in the order.
Indeed all current errors are related to mysqlnd
symbols missing:
PHP Warning: PHP Startup: Unable to load dynamic library 'mysqli.so' (tried: /usr/lib/php/20190902/mysqli.so (/usr/lib/php/20190902/mysqli.so: undefined symbol: mysqlnd_global_stats), /usr/lib/php/20190902/mysqli.so.so (/usr/lib/php/20190902/mysqli.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'pdo_mysql.so' (tried: /usr/lib/php/20190902/pdo_mysql.so (/usr/lib/php/20190902/pdo_mysql.so: undefined symbol: mysqlnd_allocator), /usr/lib/php/20190902/pdo_mysql.so.so (/usr/lib/php/20190902/pdo_mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
This is so, so weird!
Yes, this could absolutely be the issue. But the fact is that I'm making sure that mysqlnd
is loaded if mysqli
is loaded (here)
The only explanation I could find is that we have a race condition:
exec
uted but Docker does not wait for the entrypoint to ends (now that I think about it, it makes sense because Docker has no way to know if it is in the entrypoint or in the command)I could of course change the order of the array here to make sure mysqlnd is enabled before the other extensions, but that would only change the kind of issue you are seeing (mysqlnd would be enabled, but other extensions would not)
The only solution I see around this would be to shadow the "php" command to run the extensions setup BEFORE running the real "php" command itself (basically, I could write a small bash script in place of "php" that read environment variables, configures PHP and then starts PHP). The problem is that this could slow the start of the "php" command a bit. This is related to https://github.com/thecodingmachine/docker-images-php/issues/91#issue-382103517
Can you confirm to me that if you put a "sleep" between the "docker-compose up" and the "exec", you are not seeing these errors anymore?
Yes, as mentioned above (https://github.com/thecodingmachine/docker-images-php/issues/200#issuecomment-647582813) sleeping for a while already reduces the risk of this error showing up. It doesn't disappear completely since the issue also depends on I/O speed but sleeping for e.g. 30 seconds is not really an option since it would slow down our builds dramatically.
One thing I'm not sure about ATM:
On startup, the entrypoint enables all extensions one by one
This is not the case AFAIS:
Here all PHP extensions to enable are requested to be enabled at once. This would lead to the issue linked before that phpenmod
orders the extensions by name which would e.g. put mysqlnd
after mysqli
.
But as you said changing something here probably wouldn't help much: as soon as a PHP process is started while PHP extension setup is not yet finished, it will run with the state of its startup and won't change afterwards unless subprocesses are used.
However, I think I was able to avoid the issue for now by doing the following right after docker-compose up
and before my actual docker-compose exec
:
docker-compose exec -T <service> dockerize -wait file:///etc/php/7.4/cli/conf.d/10-mysqlnd.ini -wait file:///etc/php/7.4/cli/conf.d/20-mysqli.ini -wait file:///etc/php/7.4/cli/conf.d/20-pdo_mysql.ini
So instead of waiting for the library files (.so
) which should actually exist all the time I now wait for the symlinks which enable the PHP extensions. (Verified once more by looking into the source of phpenmod
).
Now the job works just fine:
And one can see that phpenmod
is considerably slow, at least in our environment:
2020/06/23 11:01:50 Waiting for: file:///etc/php/7.4/cli/conf.d/10-mysqlnd.ini
2020/06/23 11:01:50 Waiting for: file:///etc/php/7.4/cli/conf.d/20-mysqli.ini
2020/06/23 11:01:50 Waiting for: file:///etc/php/7.4/cli/conf.d/20-pdo_mysql.ini
2020/06/23 11:01:56 File file:///etc/php/7.4/cli/conf.d/20-mysqli.ini had been generated
2020/06/23 11:01:57 File file:///etc/php/7.4/cli/conf.d/20-pdo_mysql.ini had been generated
2020/06/23 11:01:58 File file:///etc/php/7.4/cli/conf.d/10-mysqlnd.ini had been generated
I'm not sure how to fix this properly TBH ...
I also tried to add the PHP_EXTENSIONS
to the image we are building anyways but that didn't work as expected. I defined PHP_EXTENSIONS: gd mysqli pdo_mysql
as build arg and removed the environment variable of the same name.
Then I did a build (based on 7.4-v3-fpm-node8
) but that brought up this message:
[Warning] One or more build-args [PHP_EXTENSIONS] were not consumed
Since the fat images are based on the slim images I assumed that one could also prebuild these images with PHP extensions. (If possible I would not use the slim images since then I'd need to install Node/NPM myself.)
After giving this one more thought I found an (embarrassingly simple) solution:
Do not use docker-compose up -d && docker-compose exec <command>
but simply docker-compose run --rm <command>
.
This way the <command>
is executed by the entrypoint itself and can be 100% sure that all dependencies like PHP extensions have been set up before:
With up -d
setup can still happen in the background while exec
is already running. This is the root cause for the issue I saw here.
So no waiting for files via dockerize
etc. is necessary once I start to do the right thing :tm:
Of course, all other services relevant for execution (e.g. mysql
) must be mentioned in depends_on
then, otherwise they are not started at all.
I'll watch this for a while but I'm actually convinced that the issue has been resolved now. In any case thank you @moufmouf for this amazing piece of development for developers. :-)
Thanks for the feedback @mbrodala !
Actually, I'll keep your issue open. I've been beaten by a "somewhat" similar problem. I'm using PHPStorm and when declaring a PHP interpreter in Docker, PHPStorm tries to detect Xdebug by connecting to the container but completely bypassing the entrypoint. As a result, it does not find XDebug at all (since it is set up in the entrypoint) and fails.
The more I think about it, the more I'm convinced I need to "shadow" the "php" executable behind a simple script that will install the extensions before triggering php itself.
That could probably work but then you'll also need to do the same for php-fpm
for non-CLI executions ...
I'm having a similar problem just trying to load the redis extension, with the following error:
php-apache-slim_1 | PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20180731/redis.so (/usr/lib/php/20180731/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20180731/redis.so.so (/usr/lib/php/20180731/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
php-apache-slim_1 | PHP: syntax error, unexpected '(' in /etc/php/7.3/cli/conf.d/generated_conf.ini on line 2
php-apache-slim_1 | PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20180731/redis.so (/usr/lib/php/20180731/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20180731/redis.so.so (/usr/lib/php/20180731/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
php-apache-slim_1 | bash: line 2: syntax error near unexpected token `('
php-apache-slim_1 | bash: line 2: `Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20180731/redis.so (/usr/lib/php/20180731/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20180731/redis.so.so (/usr/lib/php/20180731/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0'
ims__php-apache-slim_1 exited with code 2
Using the following Dockerfile
:
ARG PHP_EXTENSIONS="apcu mysqli sqlite3 pgsql bcmath soap gd intl gmp imagick xdebug redis"
FROM thecodingmachine/php:7.3-v3-slim-apache
And the following docker-compose.yml
:
version: '3.5'
services:
php-apache-slim:
build:
context: ./docker/php-fpm
volumes:
- ./:/var/www/html
ports:
- "80:80"
Anything I'm doing wrong here?
@thiagomeireless Which of these reflect your workflow:
docker-compose up -d
followed by docker-compose exec php-apache-slim ...
docker-compose run --rm php-apache-slim ...
The 1st suffers from the issue mentioned here, the 2nd one will work just fine.
@thiagomeireless Which of these reflect your workflow:
docker-compose up -d
followed bydocker-compose exec php-apache-slim ...
docker-compose run --rm php-apache-slim ...
The 1st suffers from the issue mentioned here, the 2nd one will work just fine.
Both workflows throws the same errors for me:
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
/usr/local/bin/docker-entrypoint-as-root.sh: line 129: supercronic: command not found
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
bash: line 2: syntax error near unexpected token `('
bash: line 2: `Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0'
I found a similar issue in another repo and it might be related to php-igbinary
version.
In any case my issue is resolved.
Reopening since this is still an issue when using exec
. This should be taken into account and checked for newer image versions where there are plans for a different way to set up PHP extensions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please update it if any action still required.
Yes, it is.
Yes, it is.
Sorry, please can you provide a digest about the issue and related information to reproduce ? This issue mixed with v3 (no more supported) so maybe another topic may help to identify the actions that we have to do.
To put it simply, and this applies to v4
too:
docker compose up -d
docker compose exec
in this service which involves PHPAt this point sometimes PHP or the init script is not yet done with setting up all PHP extensions which leads to errors like mentioned here.
This also means that the error cannot occur with docker compose run
since the command is definitely not executed before the init script has finished. But this is only an option for a few cases.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please update it if any action still required.
Yup, still unresolved.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please update it if any action still required.
No update, no fix yet.
I assigned a bug tag to deny the autostale bot. I agree with you and its a design issue. To start the container, compose start then execute the entrypoint. In this entrypoint, some configuration (like install / configure some php extensions) are doing... but for the manager (here composer), the container is already in running status.
A workaround is to add an healcheck (like it's described here https://medium.com/@saklani1408/configuring-healthcheck-in-docker-compose-3fa6439ee280 ). Another way to manage that could be nice but i do not have smart idea to doing it in v4.
I also had the idea to extend the healthcheck accordingly but didn't succeed yet. Also my last attempt would be costly since it would mean invoking a command which e.g. tries to establish a DB connection only to ensure that the necessary DB extensions for PHP are loaded successfully.
We'd need something else instead which really queries PHP which extensions are loaded ATM and compares this to the list of requested extensions ...
Expected Behavior
Container PHP usage should work without any warnings and all the time.
Current Behavior
We randomly/often get warnings like these with the PHP containers:
We currently use the
thecodingmachine/php:7.2-v3-fpm-node8
image withPHP_EXTENSIONS: gd
only, so these extensions are not disabled intentionally.However, the error sounds more like the extension does not exist at all ...
Context
For some unknown reason this error currently only occurs in our CI environment causing various build failures. So far we haven't been able to trigger this locally.
Your Environment
7.2-v3-fpm-node8
Ubuntu 16.04.6 LTS