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