Matomo: Notice - unserialize(): Error at offset 0 of 53988 bytes

[Findus23]

The source of the error has been found, please take a look at #14229 for the fix.

---

This error has been reported quite a few times on the forum, so I'll create an issue.

What is known:

• It does not depend on PHP version
• it often occurs with 3.9.0, but somone already reported this for 3.8.1
• it does not occur on any of my Matomo instances
• reverting #13923 fixes the issue (see https://github.com/matomo-org/matomo/issues/14229#issuecomment-474391461)
• it only occurs during archiving (if you see the error somewhere else, please comment)
• ???

https://forum.matomo.org/t/empty-or-invalid-response/31848
https://forum.matomo.org/t/empty-or-invalid-response-when-core-archive/32106
https://forum.matomo.org/t/error-making-archive/32110

[comete-upn]

We encounter the same error since updating to Matomo 3.9 this morning.

We are using PHP 7.0.33 though.

[ZAZmaster]

Has same issue!

[Guite]

Same problem since updating to Matomo 3.9. Using PHP 7.2.

[mattab]

Is the problem maybe that some logging seems to be enabled? eg. the response is:

ERROR [2019-03-19 06:38:22] 17061  Empty or invalid response '[2019-03-19 06:38:21] piwik.DEBUG: Loaded plugins: CorePluginsAdmin, CoreAdminHome, CoreHome, WebsiteMeasurable, IntranetMeasurable, Diagnostics, CoreVisualizations, Proxy, API, ExamplePlugin, Widgetize, Transitions, LanguagesManager, Actions, Dashboard, MultiSites, Referrers, UserLanguage, DevicesDetection, Goals, Ecommerce, SEO, Events, UserCountry, VisitsSummary, VisitFrequency, VisitTime, VisitorInterest, ExampleAPI, RssWidget, Feedback, Monolog, Login, TwoFactorAuth, UsersManager, SitesManager, Installation, CoreUpdater, CoreConsole, ScheduledReports, UserCountryMap, Live, CustomVariables, PrivacyManager, ImageGraph, Annotations, MobileMessaging, Overlay, SegmentEditor, Insights, Morpheus, Contents, BulkTracking, Resolution, DevicePlugins, Heartbeat, Intl, Marketplace, ProfessionalServices, UserId, CustomPiwikJs, BotTracker, QueuedTracking, ReferrersManager, SecurityInfo [] {"class":"Piwik\\Plugin\\Manager","request_id":17148} a:52:{s:10:"2019-01-27";a:40:{s:16:"nb_uniq_visitors";d:5;s:9:"nb_visits";d:5;s:8:"nb_users";i:0;s:10:"nb_actions";d:5;s:11:"max_actions";d:1;s:12:"bounce_count";d:5;s:16:"sum_visit_length";i:0;s:19:"nb_visits_returning";d:1;s:20:"nb_actions_returning";d:1;s:26:"nb_uniq_visitors_returning";d:1;s:18:"nb_users_returning";i:0;s:21:"max_actions_returning";d:1;s:21:"bounce_rate_returning";s:4:"100%";s:30:"nb_actions_per_visit_returning";d:1;s:26:"avg_time_on_site_returning";d:0;s:14[...................]

and the first line is ERROR [2019-03-19 06:38:22] 17061 Empty or invalid response '[2019-03-19 06:38:21] piwik.DEBUG: Loaded plugins:

Can you maybe check that DEBUG logging is disabled? https://matomo.org/faq/troubleshooting/faq_115/

[Guite]

log_level is set to WARN in global.ini.php and does not exist in config.ini.php.
But indeed the cronjob's output contains DEBUG messages.

[ZAZmaster]

global.ini.php log_level = WARN
In system check: Last Successful Archiving Completion Archiving has not yet run successfully.

[dogsbody]

I believe I have the same issue since upgrading to Matomo 3.9.0 this morning.
Ubuntu 18.04 with PHP 7.2

[arndbernstein]

Same here. I also get a "Password changed" mail each time I login via LDAP.

[maisen20]

same here. maybe this issue will have a lot other users.

[creopard]

Using the "real" cron feature for the first time in Matomo 3.9.0 and got this error straight away.
Changing the "log_level" to e.g. "ERROR" does not seem to fix it.

[poldixd]

Same issue here:

Matomo-Version: 3.9.0
MySQL-Version: 5.5.60-0+deb7u1-log
PHP-Version: 7.2.14

[fdellwing]

I did stumple across an interessting case:

Our archiving was running fine with php7.0 (I hardcoded it sometime ago in the cron, website runs 7.2). I just ran the command with php7.2 and got the error, afterwards I was not able to run the command with php7.0 again.

[Findus23]

@fdellwing As I have no idea why this could happen, I'd suggest running console cache:clear and checking if this fixes it again (until you repeat the steps)

[fdellwing]

Clearing the cache did not solve the problem.

[fdellwing]

Ok, this error is definitely a regression of #13923

You may apply the attached patch file to your Matomo instance to revert these changes until the problem is solved.

git apply --reject ~/0001-Revert-Enable-fingers-crossed-handler-via-INI-config.patch

(Calling with --reject because some files are not packed into release)

0001-Revert-Enable-fingers-crossed-handler-via-INI-config.patch.txt

//cc @diosmosis

[timEulitz]

@fdellwing Your patch seems to work fine for us, thanks a lot!

Do we have to keep anything in mind when updating Matomo via the user interface the next time or will it simply overwrite the patched parts of the code without causing a fuss?

[Findus23]

@timEulitz
The next update will overwrite all files, so you should be fine once you have installed it. And if some file is not overwritten, the integrity checker will tell you what to do.

[arndbernstein]

Patch solved the cron problem. Still get the password changed notification, seems to be unrelated.

[Findus23]

@arndbernstein This sounds completely unrelated, could you please open an issue here:
https://github.com/matomo-org/plugin-LoginLdap

[comete-upn]

Applying the patch solved the problem on our hand.
Thanks!

[diosmosis]

If I had to guess there is error occurring that is now visible in whatever is trying to be unserialize()'d. From what's been reported, this only happens during cron archiving, correct? If it happens at another time, please let me know.

[jgkirschbaum]

@arndbernstein This sounds completely unrelated, could you please open an issue here:
https://github.com/matomo-org/plugin-LoginLdap

https://github.com/matomo-org/plugin-LoginLdap/issues/180

[maisen20]

after apply the patch, the file integrity check fails and reports that there are some files with not the expected file sizes. did i something wrong or is that normal!?

[ghost]

Patch fixed it, thanks!

But now i get an "SQLSTATE Syntax error or access violation" when i run the cron archiving:

ERROR [2019-03-19 14:58:46] 17845 Got invalid response from API request: ?module=API&method=API.get&idSite=52&period=day&date=last52&format=php&trigger=archivephp. Response was 'a:2:{s:6:"result";s:5:"error";s:7:"message";s:427:"SQLSTATE[42000]: Syntax error or access violation: 1064 Routing query to backend failed. See the error log for further details. - in plugin Actions, caused by: SQLSTATE[42000]: Syntax error or access violation: 1064 Routing query to backend failed. See the error log for further details., caused by: SQLSTATE[42000]: Syntax error or access violation: 1064 Routing query to backend failed. See the error log for further details.";}'

I'm using MariaDB 10.3.13 Galera Cluster, maybe unrelated?

[pixel8383]

Same issue to my installation. I don't have ssh access to my hosting, how can I fix it?

[Findus23]

@maisen20 Of course if you modify the files in a not intended way by the patch, the files aren't original anymore and the integrity check complains.

When a proper fix has been developed and the next update is released, it will be overwritten again.

@pixel8383 you could download all files, apply the fix locally and upload all files again. Or you simply wait for the update and until then just don't run the archiver (data is still recorded).

[fdellwing]

Our archiving was running fine with php7.0 (I hardcoded it sometime ago in the cron, website runs 7.2). I just ran the command with php7.2 and got the error, afterwards I was not able to run the command with php7.0 again.

Just checked this again after doing manual update and this is not reproducible for me. So I guess something in the update went wrong and the cache got not cleared? Might be #14227.

[diosmosis]

@fdellwing Would you be able to get an instance that can reproduce the error?

Or is there anyone else who can reproduce the error that might be able to help debug the cause?

I'm pretty sure there are multiple issues here, one triggering the change in #13923 to be used somehow, which masks another error causing cron requests to fail. But as of yet I'm not able to reproduce it.

[fdellwing]

I'll be back at work tomorrow 08:30 CET, but yes our instance is affected as soon as I remove the patch.

[Findus23]

One guess why @diosmosis and I can't reproduce the issue:
My instances are using the beta versions and release candidates and so I never came across https://github.com/matomo-org/matomo/issues/14227 as I made the large update before it was merged and afterwards I guess the code wasn't triggered in the small update.
And so I also seem to not be affected by this.

I guess my idea of automated stable-to-stable update tests would maybe also have caught this.

@diosmosis Have you tried setting up a 3.8.1 instance and then updating to reproduce?

[michaellass]

I also see this issue and can reproduce it with quote a lot of debug output. Maybe this can help?

matomo-error.log

The last SQL statement for each error seems to be truncated. I wonder if this is just the output or the actual statement. If it's the latter it would be no wonder that it fails...

[fdellwing]

My instances are using the beta versions and release candidates and so I never came across #14227 as I made the large update before it was merged and afterwards I guess the code wasn't triggered in the small update.

You sure it is related to that issue? I even get the error if I do a manual 3 step upgrade.

[Findus23]

@fdellwing Even when you update from the release candidate to the stable version?

[fdellwing]

I only tried 3 step upgrade after the auto update failed. But I now can do it unlimited times with always the problem afterwards.

[diosmosis]

@Findus23 Yes, that's how I was able to reproduce and fix the other issue affecting the update. But I don't have an issue w/ core:archive. It's possibly due to using a mac, I'll try going through docker.

@michaellass @fdellwing The output is truncated, there's likely much more not being displayed. If PIWIK_ARCHIVE_NO_TRUNCATE is defined, you'll be able to see the whole message which would definitely help.

[michaellass]

@diosmosis thanks for the tip! Here's the full output.

matomo-error-long.log

[diosmosis]

Thanks @michaellass! Looks like there is actually no error or warning, the log level is simply changed to DEBUG for some reason, but only in those archiving requests. I'll see if I can pinpoint a cause.

[diosmosis]

@michaellass could you try the following change to see if it fixes the issue for you? comment out https://github.com/matomo-org/matomo/blob/3.x-dev/plugins/Monolog/config/config.php#L51-L62

[michaellass]

@michaellass could you try the following change to see if it fixes the issue for you? comment out https://github.com/matomo-org/matomo/blob/3.x-dev/plugins/Monolog/config/config.php#L51-L62

I tried but that's not it. The errors still occur.

[diosmosis]

I am now able to reproduce this through docker, will put up a fix as soon as possible.

[diosmosis]

@michaellass created a fix here: https://github.com/matomo-org/matomo/pull/14239

Can you see if it works for you?

[michaellass]

@michaellass created a fix here: #14239

Can you see if it works for you?

Yes, that change fixes it! :tada:

[ZAZmaster]

Ok, this error is definitely a regression of #13923

You may apply the attached patch file to your Matomo instance to revert these changes until the problem is solved.

git apply --reject ~/0001-Revert-Enable-fingers-crossed-handler-via-INI-config.patch

(Calling with --reject because some files are not packed into release)

0001-Revert-Enable-fingers-crossed-handler-via-INI-config.patch.txt

//cc @diosmosis

And what if my installation does not use git?

[diosmosis]

@ZAZmaster there's a fix here: https://github.com/matomo-org/matomo/pull/14239, it's a small change that can be applied directly. Or you might be able to workaround it by just enabling the file logger in your INI config.

[ZAZmaster]

@diosmosis thx!

[comete-upn]

The fix #14239 works perfectly.
Thanks!

[kartolo]

@michaellass created a fix here: #14239

Can you see if it works for you?

works for me too. Archiving CLI works again

[fdellwing]

And what if my installation does not use git?

@ZAZmaster Just to make you aware of this: You just need git installed to apply a patch, it does not need to be a git repo or something along those line.

@diosmosis Fix works for me.

[nathanlesage]

Can confirm, the fix in #14239 works, the Cron runs smoothly on my installation now!

[fdellwing]

A quick note, you do not need to type the changes yourself, you can just get the patch from GitHub: https://patch-diff.githubusercontent.com/raw/matomo-org/matomo/pull/14239.patch

[jhit]

Confirm #14239 works here. Had the issue after upgrading to 3.9.0 running PHP 7.0.32.

[timscha]

I can also confirm the patch is working with PHP 7.3

[ToeiRei]

Patch works with 7.3.3

[adundovi]

The patch works both on PHP 7.0 and 7.1. Tnx.

[bst2002git]

Mysql 5.7.23-23-57
PHP version: 7.2.16

Patch working

[jokermanse]

PHP 7.0.21
Patch working. Thanks!