@fvdm opened this Issue on August 6th 2016

Since I updated Piwik to v2.16.2 the installation is unstable.

  • I can no longer access stats for websites (white screen)
  • Most of the sparklines on All Websites dashboard don't render anymore
  • Tracking still works (numbers still count up)
  • Non-stats areas (like settings) work fine
  • System Check reports all green

In the logs I get:

PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\UserLanguage\Reports\GetLanguage in /home/stats/public/plugins/UserLanguage/Reports/GetLanguage.php on line 16

What I attempted to resolve this issue:

  • Clear all caches with the console
  • Reset permissions (0666 for files, 0777 for dirs)
  • Again clear all caches with the console
  • Removed config.ini.php to trigger reinstall
  • Delete entire Piwik directory and reinstall, keeping the database
  • Increased PHP memory limit, tweaked other PHP (FPM) settings

I have no 3rd party plugins or themes installed.


When I disable the UserLanguage plugin with ./console plugin:deactivate UserLanguage the All Websites dashboard returns a Piwik error (red box) suggesting to contact myself and in the logs I see:

PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\Ecommerce\Reports\Base in /home/stats/public/plugins/Ecommerce/Reports/Base.php on line 17

Then I enable the plugin and at first everything is still broken until the cronjob runs ./console core:archive and somehow all dashboards, stats, graphs everything seems ok. But a minute later the first graphs on a website dashboard fail to load, producing error:

PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\VisitorInterest\API in /home/stats/public/plugins/VisitorInterest/API.php on line 23

For

POST /index.php?date=2016-08-06&module=VisitorInterest&action=getNumberOfVisitsPerVisitDuration&widget=1&viewDataTable=cloud&isFooterExpandedInDashboard=true&idSite=6&period=day HTTP/2.0

Eventually hours later the whole Piwik installation is broken again.

@tsteur commented on August 7th 2016 Member

From which version did you update and how did you update?

On what operating system is that?

@fvdm commented on August 7th 2016

I don't remember the exact version, it was the latest stable release before this one. And I ran the built-in updater in the Piwik UI, all steps until completion and without any errors.

Environment:
CPU 4 cores, 8GB RAM (not swapping)
Ubuntu 15.10 x86_64
PHP 5.6

@fvdm commented on August 7th 2016

Btw, database size is 992.4 MB according to Piwik settings.

Edit:
Also worth to note is that the API appears to be functioning just fine.

@fvdm commented on August 8th 2016

Follow up: when I disable all caching in config.ini.php everything works great! So the problem must be somewhere in the caching.

[Cache]
backend = "null"

Edit:
Nevermind, back to square one.

@tsteur commented on August 8th 2016 Member

That's really weird. Is there any chance that we can get access to your server? If so please send us an email to hello at piwik.org and leave a comment here afterwards as it might go to spam.

Maybe also try to remove files in tmp tmp/*.json, tmp/assets/*, tmp/cache/*, tmp/templates_c/*

@fvdm commented on August 8th 2016

Removing the tmp files and then forced rearchive appears to be the solution.

There are no *.json files in tmp/, but after deleting the contents of assets, cache and template_c most reports came back. For a few I had to double refresh the page, but some reports like Visitors/Engangement and Actions/Pages (and more under Actions specifically) kept returning the red error. Then I ran:

./console core:archive --piwik-domain "{private}" --force-all-websites --force-all-periods

Took a long time to complete, but now the issue appears to be resolved. I checked the permissions before deleting the tmp/ files and they all had proper read/write access.

Interesting to note is that the response time to clicks has improved a lot! It's near instant even on large reports.

@tsteur commented on August 8th 2016 Member

Re the instant loading times maybe it's also related to http://piwik.org/docs/setup-auto-archiving/ in case this is not activated it will improve loading time a lot.

Maybe Piwik had no permission to reset some caches or something else happened. I still cannot really explain it but happy it works now. Can we close this issue?

@fvdm commented on August 8th 2016

I already had auto archiving with cron.

Anyways, thanks a lot for the hints and yes you can close the issue.

@fvdm commented on August 12th 2016

@tsteur After 3 days without any trouble the problem returned, similar to before.

PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\UserLanguage\Reports\GetLanguage in /home/stats/public/plugins/UserLanguage/Reports/GetLanguage.php on line 16

Piwik

  • All Websites Dashboard (AWD) loads ok, except for the sparklines although some of them (random) sometimes do load.
  • Settings works fine.
  • Tracking and API work fine. (including the Piwik Mobile 2 app)
  • DBStats is a white screen.
  • System Check is all good. (green)
  • Any website report is a white screen.
  • When I enable debug log it only reports loaded plugins.
  • Disabling the cache in the config.ini.php returns the red error on AWD and white screen on reports.
  • Clearing the cache with ./console cache:clear and then ./console core:archive causes always red error on AWD and still white reports. (not recovering)
  • Deleting tmp/ contents with rm -rvf {assets,cache,templates_c}/* and then run ./console core:archive does bring back the AWD with broken sparklines and still white reports.

Server

  • The process has read and write access to all contents of the tmp/ directory. Actually to the entire piwik path and of course execution perms for directories.
  • There are no cron jobs running that could affect Piwik, besides normal core:archive.
  • Piwik has its own installation path outside any site or app, not sharing its database or DB login with anything else.
  • Server load is low, plenty of RAM available, not swapping, no weird processes, PHP and MariaDB are running fine, everything looks healthy.
  • PHP memory_limit = 256MB should be plenty.
@fvdm commented on August 12th 2016

Okay weird, it appears the tmp/ has nothing to do with it. Somehow the permission of the other files change at random. Only when I run this in the Piwik root it fully recovers:

sudo find . -type f -exec chmod 0660 {} \;
sudo find . -type d -exec chmod 0770 {} \;

Edit: (6:18)
Nevermind, it's broken again.. The chmod trick was just lucky.

@tsteur commented on August 12th 2016 Member

Is it possible that we get access to that server?

PHP memory_limit = 256MB should be plenty.

It depends, if possible I'd increase it but it depends how much traffic your sites get. It shouldn't cause such an error though.

Somehow the permission of the other files change at random

This sounds a bit weird, it shouldn't change by random. Maybe there are different processes running or something must be causing this.

Have you installed from the zip download from our website or from git? Which version of PHP 5.6 is it?

@glipman commented on August 13th 2016

For the record: I seem to be having very similar problems after the upgrade to the latest version.
Initially (after a apache restart) all widgets work as expected but after a few refreshes they show an 'Internal server error' and the logfiles shows messages about redeclared classes.

Mine is a tiny installation (only 50-100 hits/day since the beginning of this year).

Piwik is running on virtual Turnkey Linux with PHP Version 5.6.24-0+deb8u1
uname -a: Linux piwik 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

@glipman commented on August 13th 2016

Update: I think I found a solution: xcache seems to be the problem.
https://www.drupal.org/node/2066561 describes a similar problem so in my "\etc\php5\mods-available\xcache.ini" is set xcache.size = 0 and restarted apache.

Since then I have not seen the 'redeclare class' again, Piwik is working fine.

Nevertheless it is something you might want to investigate. XCache is very common.

@tsteur commented on August 14th 2016 Member

@fvdm can you confirm you are using xcache as well? We would need to check if there were any changes re xcache.

@fvdm commented on August 14th 2016

@tsteur Ah yes of course, I have opcache and xcache running but never realized you can have only one at a time! A cache can't serve another cache. That explains the "Cannot redeclare class" errors.

I disabled opcache now and keep monitoring.

@glipman Do you perhaps also have multiple caches enabled in PHP?

@glipman commented on August 14th 2016

Indeed, in my installation opcache was enabled as well.
Once you know what to look for you can find it all over the Internet when you google for 'opcache xcache redeclare'.
I did not enable it myself, it came this way with my Turnkey LAMP appliance. They seem to have tackled this in newer versions already.

In the end I believe Piwik is doing nothing wrong and no software change is required. Adding an entry to installation FAQ might be an idea though.

@fvdm commented on August 14th 2016

I'm still curious what caused the problem in Piwik only since the update. Other apps like Wordpress don't have a problem with the mixed caches.

Edit: re the changing permissions, it was my server-wide security script that was a little too aggressive.

@tsteur commented on August 14th 2016 Member

I had a look through the changes but don't know what it causes, maybe an update of a library. We would probably simply recommend to have only one cache active in general and I would say we add a system check for it. I will update the title to add a system check

@fvdm commented on August 14th 2016

Addition to the System Check would be great.

@fvdm commented on August 17th 2016

Sadly the problem just returned. Nothing has changed on my server except for disabling opcache two days ago based on this conversation. Everything else is looking good and I'm not getting any errors in the UI.

  • On the AWD most sparklines return error 500 PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\API\Reports\Get in /home/stats/public/plugins/API/Reports/Get.php on line 15
  • and any website report I click from there brings only a white screen and error PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\UserLanguage\Reports\GetLanguage in /home/stats/public/plugins/UserLanguage/Reports/GetLanguage.php on line 16

AWD screenshot

So it's not in the caching. 😞

@mattab commented on August 17th 2016 Member

Hi @fvdm just a basic check: did you try to restart your webserver?

@fvdm commented on August 17th 2016

Hi @fvdm just a basic check: did you try to restart your webserver?

Hi @mattab I don't feel like rebooting an entire server because a webapp is acting up.

@fvdm commented on August 17th 2016

I'll get to the bottom of this. Right now Piwik is working perfectly normal somehow, while nothing has changed except for new tracking input.

When I have time I shall move Piwik to its own PHP process so I can revert the php.ini to all defaults and disable all extensions. Debug step by step.

@fvdm commented on August 19th 2016

Alright I found the problem, there was yet another cacher enabled in one of the included ini's!

What a mess, I'm completely rebuilding the server now to avoid these kind of issues in the future. Five years of patches and tweaks stacked upon eachother. My guess is the Piwik update did change something in a good way, more adhering to modern standards or the like, which caused the ancient code higher up the chain to finally break.

Issue resolved!

@tsteur commented on August 19th 2016 Member

Thank you for letting us know. I still think a system check would be good for usability in case something like this happens again. It's an edge case but easy to implement.

@mattab commented on December 26th 2016 Member

@fvdm what was the third cache that you had enabled?

@fvdm commented on February 7th 2017

@mattab Sorry, I forgot about this. The other one was APCu.

Although opcache and apcu should have worked great together. It probably was a rogue config somewhere, maybe cache expiry not well aligned.

The new ssd server is running so great using only opcache, I even managed to downgrade the VPS to 4GB ram and 3 cpu cores. :moneybag:

@mattab commented on May 19th 2020 Member

Thanks for contributing to this issue. As it has been a few months since the last activity and we believe this is likely not an issue anymore, we will now close this. If that's not the case, please do feel free to either reopen this issue or open a new one. We will gladly take a look again!

This Issue was closed on May 19th 2020
Powered by GitHub Issue Mirror