Won't Work, No Debug Output Produced Either!

[tjharman]

I can't get OpCache to work! I'm using the latest version from git, cloned fresh just now.

I have no problems using eaccelerator or xcache, but attempts to get OpCache to work keep failing me.

I have compiled like so:

phpize ./configure --with-php-config=/usr/bin/php-config make

Then copied the binary from modules to my php5 modules directory, which is /usr/lib/php5/20090626+lfs/

If I look a simple phpinfo() output, I see that it's running:

Opcode Caching Up and Running Optimization Enabled Startup OK Shared memory model mmap

Yet attempts to run things like Squirrelmail, Roundcube or my Drupal site just result in errors. However, there's nothing in /var/log/apache/error.log. And, most alarming of all, even though I've set opcache.error_log = "/tmp/opcache.log" opcache.log_verbosity_level = 4 There is no /tmp/opcache file generated. Even if I leave the error_log blank, nothing is written to the apache log file. What am I doing wrong here? It's like it's only half running. My setup: Debian 6.0.7 PHP 5.3.3-7+squeeze16 with Suhosin-Patch (cli) (built: Jul 17 2013 17:04:11) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend Technologies with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH root@beaker:~# apache2 -v Server version: Apache/2.2.16 (Debian) Server built: Mar 3 2013 11:36:05 gcc version 4.4.5 (Debian 4.4.5-8)

[tjharman]

tim@beaker ~/ZendOptimizerPlus> php run-tests.php

PHP : /usr/bin/php PHP_SAPI : cli PHP_VERSION : 5.3.3-7+squeeze16 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux beaker 3.9.8-grsec #1 SMP Fri Jun 28 14:23:44 NZST 2013 i686 INI actual : /etc/php5/cli/php.ini More .INIs : /etc/php5/cli/conf.d/curl.ini,/etc/php5/cli/conf.d/gd.ini,/etc/php5/cli/conf.d/geoip.ini,/etc/php5/cli/conf.d/gmp.ini,/etc/php5/cli/conf.d/imap.ini,/etc/php5/cli/conf.d/mcrypt. ini,/etc/php5/cli/conf.d/mysql.ini,/etc/php5/cli/conf.d/mysqli.ini,/etc/php5/cli/conf.d/opcache.ini,/etc/php5/cli/conf.d/pdo.ini,/etc/php5/cli/conf.d/pdo_mysql.ini,/etc/php5/cli/conf.d/suhos in.ini,/etc/php5/cli/conf.d/uploadprogress.ini CWD : /home/tim/ZendOptimizerPlus Extra dirs : VALGRIND : Not used

TIME START 2013-08-19 22:55:45

PASS 001: O+ works in CLI [tests/001_cli.phpt] PASS Blacklist (with glob, quote and comments) [tests/blacklist.phpt] FAIL Bug #64353 (Built-in classes can be unavailable with dynamic includes and OPcache) [tests/bug64353.phpt] FAIL Bug #64482 (Opcodes for dynamic includes should not be cached) [tests/bug64482.phpt] PASS ISSUE #57 (segfaults in drupal7) [tests/issue0057.phpt] PASS ISSUE #79 (Optimization Problem/Bug) [tests/issue0079.phpt]

TIME END 2013-08-19 22:55:46

TEST RESULT SUMMARY

Exts skipped : 0 Exts tested : 56

Number of tests : 6 6 Tests skipped : 0 ( 0.0%) -------- Tests warned : 0 ( 0.0%) ( 0.0%) Tests failed : 2 ( 33.3%) ( 33.3%) Expected fail : 0 ( 0.0%) ( 0.0%) Tests passed : 4 ( 66.7%) ( 66.7%)

Time taken : 1 seconds

FAILED TEST SUMMARY

Bug #64353 (Built-in classes can be unavailable with dynamic includes and OPcache) [tests/bug64353.phpt] Bug #64482 (Opcodes for dynamic includes should not be cached) [tests/bug64482.phpt]

[Viveur]

appear to be in the same boat here...

phpinfo.php lists Opcache as up and running but any page with php code results in:

Internal Server Error 500

PHP 5.3.2-1ubuntu4.19 with Suhosin-Patch

[tjharman]

That's two of us with teh Suhosin patch. I wonder if it's the problem? I can't really remove it though, as it's part of my Debian install.

[TerryE]

I must admit that that was my thought. It sound like you guys are running Ubuntu 10.04-LTS, or the Debian equiv. I might dig out an old VM and try out Debug OPcache build under gdb to see what is going on. However, IIRC the Suhosin patch does some nasty things to lock down the Zend Engine so I am not surprised that you've got problems.

---

PS. On reflection, I think that this is the wrong answer. I've found an issue and fix with an old versions of 5.4 (<5.4.11 if I recall), but the response is that it isn't policy to change OPcache to work around issues in non-supported PHP versions. 5.2.3 and 5.3.3 are way behind current. Suhosin is an added complication. My suggestion would be to use the Debian install of APC or Xcache for this old version if this works for you and OPcache doesn't. If you can replicate the issue on the current PHP 5.3 without Suhosin, then this would be a different issue.

[tjharman]

Ok, thanks TerryE. I just wanted to test it out compared to XCache. I figure that targeting an up-to-date version is much better than trying to support an old Debian version.

My only suggestion would be to update the README or similar with a note to this affect, that trying to use ZendCache under older versions probably won't work.

Thanks!

[trunet]

I'm with exactly same problem on ubuntu 12.04 with php5-fpm + zendoptimizerplus

[TerryE]

The standard Ubuntu 12.04, unless you've rebuilt PHP with a current build, then my previous answer applies. If not please post back with specifics of PHP versions, etc.

[knotenpunkt]

i have the same problem... php version: 5.3.10 with suhosin patch but i dont think that the suhosin patch is the problem.....

if i open my website and i have in the website only one php file with maybe phpinfo or echo "hello" world, then this is displayed (maybe this go not through the opcache or throug the php5-fpm (which i use too))

but if i want to show a complex website, then nginx says: bad gateway it isnt a ngnix problem (if i call this website direct about apache: no content is shown)

i think the problem is at the output, because if i look into my databases and into my session system then i see the php script worked, but only the output is missing

i think opcache routes the output wrong or opcache produce an error at the output to apache

the suhosin patch isnt a problem, because if i call my website with php cgi -> the website is shown...

i hope you can solve the problems and release the next version very fast

Just know i have to use xcache, but i want change to opcache

[zeleznypa]

I can also confirm this problem. Ubuntu 12.04 LTS + php5-fpm package will produce exactly the same error described in previous comment.

[jpommer]

Debian Wheezy as well, PHP 5.3.10-1ubuntu3.8 with Suhosin-Patch

Apache error log shows segfaulting child processes when a request comes in.

[jpommer]

[pid 9737] munmap(0x7f39cfcae000, 528384 <unfinished ...> [pid 9737] <... munmap resumed> ) = 0 [pid 9737] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

I'm trying to get a core dump.

[gosdenj]

Ditto ...

"Error 503 Service Unavailable"

... on anything php based that is'nt just <?php phpinfo() ?>

I'm running Ubuntu 12.04 LTS, here's the PHP version (opcache is built from pecl: http://pecl.php.net/package/ZendOpcache):

php -v

PHP 5.3.10-1ubuntu3.8 with Suhosin-Patch (cli) (built: Sep 4 2013 20:05:42) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH

Apache2 version:

apache2 -v

Server version: Apache/2.2.22 (Ubuntu) Server built: Jul 12 2013 13:38:21

It's a real shame, back to XCache for the time being.

[TerryE]

@Bit32 @trunet @knotenpunkt @jpommer @zeleznypa @gosdenj

Please read the complete set of comments before posting:

I've found an issue and fix with an old versions of 5.4 (<5.4.11 if I recall), but the response is that it isn't policy to change OPcache to work around issues in non-supported PHP versions. 5.2.3 and 5.3.3 are way behind current. Suhosin is an added complication... If you can replicate the issue on the current PHP 5.3 without Suhosin, then this would be a different issue.

The current version of PHP5.3 is 5.3.27. Suhosin is not supported by PHP.net. So problems OPcache with PHP 5.3.10 + Suhosin are not considered as a bug by the OPcache developers. If the Debian maintainers want to issue a patch to OPcache to extend bugfixes back to 5.3.10 then that is their call.

BTW. I am just a community developer so have no input into this policy; I am just the messenger.