How to diagnose errors from core:archive action?

Support & Bugs
1

Hi there. I’ve been getting errors from my core:archive runs lately, but I don’t even know where to find the errors so I can start tracking down the problem!

Here’s what I get from the actual core:archive action - it’s not so useful:

                                                                                                  
  [Exception]                                                                                     
  10 total errors during this script execution, please investigate and try and fix these errors.  
                                                                                                  


Exception trace:
 () at /tools/piwik/core/CronArchive.php:410
 Piwik\CronArchive->logFatalError() at /tools/piwik/core/CronArchive.php:403
 Piwik\CronArchive->end() at /tools/piwik/core/CronArchive.php:262
 Piwik\CronArchive->Piwik\{closure}() at /tools/piwik/core/Access.php:456
 Piwik\Access::doAsSuperUser() at /tools/piwik/core/CronArchive.php:263
 Piwik\CronArchive->main() at /tools/piwik/plugins/CoreConsole/Commands/CoreArchiver.php:27
 Piwik\Plugins\CoreConsole\Commands\CoreArchiver->execute() at /tools/piwik/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:257
 Symfony\Component\Console\Command\Command->run() at /tools/piwik/vendor/symfony/console/Symfony/Component/Console/Application.php:874
 Symfony\Component\Console\Application->doRunCommand() at /tools/piwik/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at n/a:n/a
 call_user_func() at /tools/piwik/core/Console.php:79
 Piwik\Console->Piwik\{closure}() at /tools/piwik/core/Access.php:456
 Piwik\Access::doAsSuperUser() at /tools/piwik/core/Console.php:80
 Piwik\Console->doRun() at /tools/piwik/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at /tools/piwik/console:27

My first step was to check my php5-fpm logs on both piwik machines (since I’m running behind nginx, two load-balanced instances). Nothing, even though I’ve set catch_workers_output = yes in my www.conf file.

Then I checked out diagnostics, and things are looking good there. All green checks except for a LOAD DATA INFILE error under Database abilities and “not using one of the recommended providers” under Geolocation. So that doesn’t seem to be the problem.

Finally I installed the LogViewer plugin and re-ran a few failing core:archive actions, but I’m still getting this error when I try to view the logs:

Specified path to log file does not exist: /tools/piwik/tmp/logs/piwik.log

I’m confused, because the tmp directory is there and I have the recommended defaults in my config.ini.php:

[log]
; Possible values are "screen" (default value), "file" and "database" (logs to tables logger_*)
log_writers[] = file
; Possible values are ERROR, WARN, INFO, DEBUG
log_level = WARN
; if configured to log to file, log entries will be written to this file
logger_file_path = tmp/logs/piwik.log

What’s my next step? Is the LogViewer even the right thing to try to diagnose this? Is there an extra-verbose mode for the core:archive command that would give me more information?

PS: You may be wondering if these errors are real problems. Seems like they definitely are. I seem to be capturing all new visits, because they’re hitting my Visitor Log, but very few other tables and charts show data. I’ve been using Piwik for almost three years now, and this is the only major failure I’ve run into on an upgrade. Would really appreciate some help!

2

Another user here, so take my word for the 1.99999 cents it is worth.

First, have you checked the troubleshoot guide and more specifically, the issue that plagues MySQL users … Cron Auto-Archiving timeout issue

Second, logging. Part 1. I had lots of trouble getting piwik logging to work as appears to be intended… Changing config values as you did, did nothing for me. Rather, all output from the cronjob was sent to the log file using redirection (see the cronjob entry and where >> redirects output.)

Logging part 2. The problem might be permissions related. If you run the cronjob as Apache, make sure that user can write to the tmp directory)

3

Thanks for the encouragement! I tried running the core:archive command on one of my piwik/php5-fpm machines, and it looks like it worked successfully. One detail I hadn’t mentioned before is that because I’m in a load-balanced config, I had been running the core:archive command on a separate machine, no logging installed. But I can get it installed now that I know! When I get the ‘10 errors’ that are new due to v2.15.0 I’ll be back!

4

Load-balancing Piwik doesn’t really help: the database is the bottleneck. (OK, if you need to load balance your incoming HTTP connection load, yes). If you’re running the archive script from multiple clients onto a single database server, there is a very good chance things won’t work correctly. (Again, I’m not a developer of this product). If you do manage to run it in a way that one cronjob doesn’t conflict with another, then you should see in the logs (provided those work correctly) that it has been too close in time to a previous run and the archive process will essentially do nothing. So I propose you run this cron job from only one host.

5

The load balancing is more to take my app servers out as a single point of failure. I can take one down for maintenance with no problem. As far as running core:archive, I’m definitely doing it on just one machine. And it’s not one of my multiple load-balanced machines, as you recommend.

And having it on a separate machine turns out to be the source of part of problem. I had thought I updated my core:archive-runner machine to 2.15.0 as well, but I hadn’t. On top of that, it appears that this problem was masked by an old config.ini.php that, as I upgraded to newer versions, no longer properly enabled logging… Or at least, that’s all I can determine.

But it’s working now. Thanks for all your help, everyone.

6

Just to clarify: the source of the problem was that you were doing core:archive via cronjob from a separate (non production) server which had an older version installed and an incorrectly config file?

7

Yep, that seems to be it.

Note that the config file is the same one I’d been using since many months ago. That might be an interesting thing to call out in the release notes: breaking config file changes.