|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58469 apc.include_once_override turn on issue
Submitted: 2008-12-19 05:10 UTC Modified: 2009-04-05 23:31 UTC
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: paulgao at yeah dot net Assigned:
Status: Wont fix Package: APC (PECL)
PHP Version: 5.2.5 OS: Slackware
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2008-12-19 05:10 UTC] paulgao at yeah dot net
When turning the apc.stat and apc.include_once_override options On, some php files(updated via Rsync) wouldn't be executed when other files included them, so functions or classes defined in those files remain undefined.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-19 06:12 UTC] gopalv82 at yahoo dot com
try turning on apc.stat_ctime as well. 

Rsync messes with mtime, not ctime.
 [2008-12-19 07:54 UTC] paulgao at yeah dot net
Thx. I try. :)
 [2008-12-22 23:11 UTC] paulgao at yeah dot net
And unfortunately, after turning the apc.stat_ctime option *On*, I still got a fatal error (while the APC cache was not full) :

[23-Dec-2008 12:01:43] PHP Fatal error:  Class 'cls_new_template' not found in /home/codebase/framework/library/common.lib.php on line 5103
 [2008-12-26 05:18 UTC] gerome at delphipraxis dot net
same here - i still get this error.

i am unsure what data could be helpful to solve this error, but i am willing to provide you with any data you need (just 
ask) :-)

kind regards,
 [2008-12-26 19:27 UTC]
apc.include_once_override has some known problems.  So we can narrow this down a bit, can you verify if disabling this setting corrects the problem.
 [2008-12-26 20:48 UTC] paulgao at yeah dot net
> apc.include_once_override has some known problems.  So we > can narrow
> this down a bit, can you verify if disabling this setting > corrects the
> problem.

Yes, it works after disabling apc.include_once_override.
 [2008-12-27 12:15 UTC] gerome at delphipraxis dot net
again, same here. :-) disabling this option helps.

kind regards,
 [2009-01-29 17:43 UTC] kfaulhaber at kjfx dot net
include_once_override causes some strangeness with AtMail 
Open.  It seems to have something to do with multiple files 
of the same name, or sometimes the same file included() or 
required() from two different places.  For example, it makes 
heavy use of PEAR::DB, and I would get frequent errors that 
DB.php didn't exist.  Part of the problem is that AtMail 
Open uses relative path names, and if I recall from past 
experiences, include_once_override doesn't like this.

Two things I notice - the first http request for a file will 
succeed, future requests get a 500 error with a content 
length of 0, and there are no entries in Apache's logs.

apc.php doesn't show that all the files that have been 
cached.  For example, if I have /path/to/samename.php and 
/path/to/other/samename.php, only the first will show in the  
 [2009-02-03 23:10 UTC] gopalv82 at yahoo dot com
try doing 

apc.canonicalize = 0;

probably it's looking for "DB.php" and finding it in other directories and rewriting "DB.php" into "<first-hit>/DB.php".

Honestly, it should do exactly what PHP would do to find a file, but I suspect the current working dir stuff probably needs a quick look too.

Thanks for the update.
 [2009-02-19 14:35 UTC]
My advice is to not enable this option (it's experimental).  It's also actually not lock-safe.  PHP-5.3 I believe also fixes most of the issues this was trying to correct, so you should see a performance increase there.  Can you benchmark your code and see if you're actually seeing enough of a boost to merit using this?  If not I would prefer to mark this as a "won't fix" and list this option as highly experimental as we'll get the gains in future PHP versions anyways.
 [2009-03-30 15:24 UTC] doctorrock83 at gmail dot com
Just for information :
I was experiencing same bugs but not with rsync. It was with a common application.
I got "[Mon Mar 30 22:20:52 2009] [apc-error] Cannot redeclare class zend_translate_exception in /media/data/www/ZF/trunk/library/Zend/Translate/Adapter/Gettext.php on line 98" something like that.

*However* turning apc.stat_ctime on solved the problem.
 [2009-04-05 23:31 UTC]
Marking this as a "won't fix" for now as this is an experimental feature with known issues.  You should see gains in later PHP core releases that are similar to this feature, thank you for the bug report I'm sorry that it won't be corrected.
 [2010-01-08 15:40 UTC] mpartap at gmx dot net
..just ran into this issue with drupal7.. it should *really* be documented in the include_once_override doc that wired things may happen if apc.stat_ctime=1 is not set aswell.
 [2010-10-14 10:31 UTC] omega8cc at gmail dot com
It causes problems in Drupal 7-beta1 and also in the CiviCRM 
when apc.include_once_override = 1 is used with apc.stat = 
1. Tested with php-fpm 5.2.14.

This is why we added comment like below in php.ini for 

; apc.include_once_override
; Optimize include_once() and require_once() calls and avoid
; the expensive system calls used.
; When enabled, it breaks /admin/modules page in Drupal 7-
; and also breaks probably CiviCRM installs, for more 
; see
; The fix is to disable/remove this option OR to disable
; apc.stat = 0 and enable apc.stat_ctime = 1, like below.
apc.include_once_override = 1
apc.stat = 0
apc.stat_ctime = 1
 [2010-10-14 10:41 UTC] omega8cc at gmail dot com
I was wrong. With Drupal 7-beta1 it causes WSOD with any 
combination of apc.stat and apc.stat_ctime on/off, I had to 
disable apc.include_once_override completely to avoid this 
issue. Sorry for the too early/fast previous report.
 [2011-12-21 22:39 UTC] tilman+phpbugs at dataoverload dot de
> Marking this as a "won't fix" for now as this is an experimental
> feature with known issues.

Sadly, this isn't mentioned in the docs:

Could somebody please mention these "known issues" in the docs and maybe link to this bug report? That would have saved me -- and hopefully some others -- some time. Thanks!
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Feb 23 14:01:30 2024 UTC