Include Registry Rebuild as a part of Clone and Migrate tasks

Unless there are steps to reproduce this on the stock BOA, it is not a bug.

I have never seen anything like that on any BOA server we manage, so you may need to investigate your platforms/setup and check for duplicate code/modules etc, as "Cannot redeclare" is rather obvious message - you have duplicate code somewhere.

I'm afraid you guys might not be on the right track.

I've also experienced this issue, and it finally turned out that PHP was in fact running out of memory (aka it exceeded the memory_limit setting in php.ini). After raising the memory limit, the error disappeared.

I would strongly vote against using the apc settings listed above. For example apc.stat = 0 actually turns off the file modification checking in apc, which means that PHP won't get notified of file changes until the instance gets restarted (or the apc cache gets cleared some other way). This could lead to serious headaches, especially if you run php as a long running CGI process, like in a tipical PHP-FPM configuration.

The only APC settings we use in Barracuda are:

apc.shm_size = (tuned automatically - depends on available RAM)
apc.stat = 1
apc.stat_ctime = 1
apc.include_once_override = 0

I don't see any reason to force any other settings for APC.

And I agree, disabling apc.stat would be pretty crazy idea. It would cause all kinds of WTF if used.

omega8cc: these are safe settings.

One thing I would like to add just for the sake of the complete picture: apc.stat has its purpose. It is a performance setting of APC, and can give decent performance benefits by skipping fstat system calls - especially in a system with lots of file includes. In an advanced deployment environment, where the deployment process would make sure that caches get cleared properly, I would use it on the production servers.

In this case however, it is just a point into the wrong direction, and can cause even more headaches for users not fond of reading the documentation of various settings.

Closing.

Taking this back to active.

Have the same problem.
Fatal error: include_once(): Cannot redeclare class insertquery_mysql in /data/all/001/drupal-7.14.2-stage/includes/bootstrap.inc on line 1128
It happen sometimes. Can reproduce it a little bit. It happens specalliy after updating modules.

I searched a little bit. Looks like this is problem with PHP.
http://help.getpantheon.com/pantheon/topics/fatal_error_require_once_can...

Or it is more a problem with D7, APC and PHP.

They provide 2 solutions. One is to hack D7 Core, adding some lines of codes.
Other option is to provide a patch for PHP.
Don't love the idea to hack core, but it looks like the best way here.

Could you try if you can reproduce this issue with Redis disabled? I mean with the standard modules/cache/NO.txt control file.

While I also experienced this randomly on maybe two or three D7 sites, simple site rename helped, and then it didn't happen again (even without disabling Redis), so it is a bit too random to introduce/attempt any generic workaround.

will try it out and give feedback.

Whoops, found that the cache was disabled via NO.txt in site/domain.com/modules/cache/NO.TXT

I accessed the site via the alias dev.domain.com, works most of the time, but then the error appears again. No module updates over the day. The only thing that helps is to stop PHP-FPM and wait for the autohealing, that he daemon comes back.

grml. this does not help us.

I've seen this happen without apc, and it comes and goes. I think it has to do with the registry not being reset after a clone / migrate. It might be a drush bug since the site runs via the webserver and does not throw any error (it would in the case of a true dupe module), and in my case, the required functions are not duplicated anywhere in the tree.

From the clone/migrate log, it seems to have the path of the previous site dir, somehow, after a clone / migrate. And since all sites are owned by aegir, drush can try to include it and the one in your current site dir. So, not sure how to clear this cache / registry. I've seen it quite a bit with views plugins, but not exclusively. I think I just saw a patch to Drush 5 that addresses some of this, but it's still a mystery.

I think we could avoid this issue by rebuilding registry on the fly, as requested here: #1635598: Include Registry Rebuild as a part of Clone and Migrate tasks

Yeah, especially if we could rebuild it right after the file copy was done, before the verify. The clone / migrate won't complete in many cases because it fails on verify if the registry hasn't been rebuilt after the copy.

While waiting for #1635598: Include Registry Rebuild as a part of Clone and Migrate tasks in the Aegir official repo we could do that in our fork in the meantime.

i had the same error and it was related to a bug in php-fpm and when a call is made which should show up the warning: "call-time pass-by-reference" deprecated blabla... So check for that first :)

It is already included.