DataDog
Upgrading minor PHP version causes error in dd-trace-php until extension re-installation
Hi,
We found out that when updating from PHP 7.2 to PHP 7.3 (and probably other versions). We are getting PHP errors (EL7 RPM):
[EL7/BLA] [blah@xxxxxxx]$] php -m PHP Warning: PHP Startup: Unable to load dynamic library '/opt/datadog-php/extensions/ddtrace-20170718.so' (tried: /opt/datadog-php/extensions/ddtrace-20170718.so (/opt/datadog-php/extensions/ddtrace-20170718.so: undefined symbol: _zval_ptr_dtor), /usr/lib64/php/modules//opt/datadog-php/extensions/ddtrace-20170718.so.so (/usr/lib64/php/modules//opt/datadog-php/extensions/ddtrace-20170718.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Reinstalling dd-trace rpm ofcourse fixes this because the dd-trace.ini is re-generated.
This could be 2 things:
- We are missing some steps in the documentation which prevent this. In this case it's a documentation bug.
- It's not intended behaviour, and thus probably a packaging bug.
Either way, it would be nice that PHP upgrades/downgrades would be seamless and do need any manual interaction.
Maybe you could add RPM trigger scriptlets. So when an PHP upgrade is done, the dd_trace.ini is being regenerated automaticly.
Hi @rodehoed and thanks for opening the issue. We have definitely room to improve our packaging but let me comment point by point so I can clarify even more.
We are missing some steps in the documentation which prevent this. In this case it's a documentation bug.
We can definitely add some wording to the docs to explain that when a user upgrades php version (e.g. 7.2 -> 7.3 in your case), dd-trace needs to be re-installed (or the ini file manually edited).
It's not intended behaviour, and thus probably a packaging bug.
Just to clarify the bug: we ship .so files for all PHP versions that we support. We can also support multiple php versions in the same host, each one with each own installation. During the installation script we identify the modules directory for your selected (or default) php binary and we link an extension=... to the proper build (7.2 rather than 7.3).
In your case 7.3 took over the same modules dir from 7.2 and here comes the problem.
On top of this, apt/yum/apk is not the only php installation we have to support, we also have to support customer build of PHP (quite often actually).
I will talk to the team to come up with some proposal, of course if anyone from the community is welcome to participate.
A note for who is reading this issue: when you update PHP version remember to re-install the dd-trace-php extension and you are good to go.
@rodehoed I renamed the issue from "Major PHP upgrades will break dd-trace with undefined symbols" to "Upgrading minor PHP version causes error in dd-trace-php until extension re-installation" if this works for you.
Hi Luca,
Thanks for your thoughts! I sure do understand there are a lot caveats in this one.
Adding some extra background information. Just to understand the perspective of your customers (and our customers ofcourse :-)) The main problem is we are deploying everything automaticly and an reinstall is hard (this is also caused because dd-tracer is not in a yum repo, but that's another story). With a normal upgrade of php there would be almost no downtime. But having to reinstall the dd-tracer rpm would cause longer downtime.
As I have experience with RPM building (and not deb etc etc) I think this problem can be fixed with an rpm trigger but JUST for the distributed RPM. So it's not a generic solution (although dpg also supports it).
About the title change. I think this problem only arises when the ABI changes of PHP. And this should not be the case with a minor update but only with a major upgrade.
Hi,
Any update one this one?
About the title change. I think this problem only arises when the ABI changes of PHP. And this should not be the case with a minor update but only with a major upgrade.
I do not agree on this, we had this problem with a minor php update. 100% sure! We did not see this recently though.