| Thread Previous • Date Previous • Date Next • Thread Next |
Hey Andy, As always, thanks for your time. I agree on skipping the pull request. -Ben On 08/20/2015 12:45 AM, Andy Thompson wrote:
Actually, ignore my PRs, as there seems to be code in that area I changed that requires it. It might be best running `yum provides /etc/php.d/opcache.ini` to see if it was the RPM that added the opcache.ini, or if it was for example an upgrade from a previous php56u version that renamed the file, given edits to the original opcache.ini wouldn’t move over in the process AndyOn 20 Aug 2015, at 06:31, Andy Thompson <me@xxxxxxxxxxxx> wrote: Hi Jakov/Ben, PHP Zend extensions can conflict with others quite often. The solution is to change the ordering of how they load, in this case it was to move opcache to be the first extension to be loaded. The RPMs appear to additionally be introducing opcache as a standard extension as well. I’ve submitted 2 PRs to solve this. I’m unsure if this is the reason for Jakov’s PHP’s behaviour, but is a good start. https://github.com/iuscommunity-pkg/php56u/pull/13 https://github.com/iuscommunity-pkg/php55u/pull/15 @Jakov, you should be able to delete the /etc/php.d/opcache.ini manually, which then you might be able to see if this is the cause. Note there may be another extension opcache might conflict with, so the ordering, and/or use of the conflicting extensions might need to change. Kind Regards AndyOn 20 Aug 2015, at 00:22, Jakov Sosic <jsosic@xxxxxxxxx> wrote: On 08/17/2015 03:57 PM, Ben Harper wrote:You mentioned that you are rebuilding your php packages against httpd24. Can you reproduce this issue with stock IUS php packages?Hi Ben, sorry for the late answer, but I finally got some spare time and I found a reason for this segfault. Problem was within opcache module, and actually, problem was that I had two files: /etc/php.d/10-opcache.ini and /etc/php.d/opcache.ini Both files had same content, which is ok. Reason I had these two files was that I use puppet as CM, and in 5.6 you guys changed names of the ini files by adding enumeration in front of them, and puppet deployed this file as usual. Actually, to reproduce it, it is enough to have: zend_extension=opcache.so zend_extension=opcache.so in /etc/php.ini. While this is my mistake, I still am puzzled as to why does php segfault in this case. IMHO, php should handle multiple .so loading same as Apache does, by printing warning and ignoring the second 'zend_extension=' line... I already filed a bug upstream, so I'll just update the bug description, or open a new bug... What puzzles me though is that I remember having this problem with early 5.6.x versions (5.6.3) even with opcache disabled, so I'm kinda really lost. I'll give it a little bit more testing to see if it's stable enough to move prod to 5.6.x now. _______________________________________________ Mailing list: https://launchpad.net/~ius-community Post to : ius-community@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~ius-community More help : https://help.launchpad.net/ListHelp_______________________________________________ Mailing list: https://launchpad.net/~ius-community Post to : ius-community@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~ius-community More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
