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

Andy

On 20 Aug 2015, at 06:31, Andy Thompson <m...@andytson.com> 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

Andy


On 20 Aug 2015, at 00:22, Jakov Sosic <jso...@gmail.com> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ius-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~ius-community
Post to     : ius-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ius-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~ius-community
Post to     : ius-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ius-community
More help   : https://help.launchpad.net/ListHelp

Reply via email to