Good 'ole "Error in archiving, empty response"

Support & Bugs
1

Hi,

We have a very high traffic site and are experiencing issues during archiving. We have traced the problem down to a request made by the archive command

https://analytics.ourwebsite.com/index.php?module=API&method=API.get&idSite=XXXX&period=day&date=last52&token_auth=&format=php&trigger=archivephp

When we put this command into the browser, it takes about 40s to complete, but it does complete and the data is properly archived. When initiated from the archive ./console --force-idsites=XXXX command it returns an empty response.

Questions:

  1. Does anyone know why these execution contexts would differ in their limitations? It seems to me that a CLI context would be more permissive in terms of memory limits and execution timeouts.

  2. It looks like the console command actually makes an HTTP request (it outputs the URL above), which would invoke the php.ini related to apache, not the cli. Does anyone know which php.ini is involved?

Thanks!

2

Hi,

I wanted to share some debugging information for future googler’s. This surfaced again, so we ran the console archive command again with full verbose output.

./console core:archive --force-idsites=1234 -vvv

We saw this command

DEBUG [2018-08-30 12:06:56] 15515 /usr/bin/php5 -q /var/www/html/console climulti:request -q --piwik-domain=’’ --superuser ‘module=API&method=API.get&idSite=1234&period=day&date=last52&format=php&trigger=archivephp&pid=’ > /var/www/html/tmp/climulti/.output 2>&1 &
ERROR [2018-08-30 12:07:06] 15515 Got invalid response from API request: ?module=API&method=API.get&idSite=1228&period=day&date=last52&format=php&trigger=archivephp. The response was empty. This usually means a server error.

I installed xdebug and ran this command using the exact output from the archive command

/usr/bin/php5 -d xdebug.auto_trace=ON -d xdebug.trace_output_dir=/tmp -q /var/www/html/console climulti:request -q --piwik-domain=’’ --superuser 'module=API&method=API.get&idSite=1234&period=day&date=last52&format=php&trigger=archivephp&pid=

That segfaulted as expected and generated a massive trace file in /tmp (1.4G)

The trace file revealed that php was segfaulting at

/var/www/html/core/DataTable.php:1313

This was a call to the PHP serialize() function. I’ll try upgrading PHP.

3

By the way, in this situation there will be no errors in the log and there are no memory_limit issues in this case, so the default command output is a bit misleading here.