Lamp-modul: cron problems?

Support
,
21

I was curious once:

The option “Enable archiving via HTTP requests” in the Matomo WordPress plugin allows the archiving process to be triggered through HTTP requests instead of relying solely on server-side cron jobs or CLI commands. This feature is particularly useful for smaller websites or environments where configuring cron jobs is challenging.
Technical Implementation
1. Triggering via HTTP Requests:
• When this option is enabled, archiving is triggered by specific HTTP requests. A special parameter (trigger=archivephp) is used in the request to initiate the archiving process. This requires the request to be executed by a user with Superuser permissions.
• The Matomo API (CoreAdminHome.archiveReports) is utilized to start the archiving process, aggregating data from visit logs and generating reports.
2. Integration with WordPress:
• In the WordPress context, this feature can be enabled via the wp-config.php file by adding the following code:
define('MATOMO_TRIGGER_BROWSER_ARCHIVING', true);
This allows archiving to be triggered directly through browser activity or HTTP requests.
3. Asynchronous Processing and CURL:
• Archiving can be performed either synchronously or asynchronously. For asynchronous processing, a CURL request is used to execute the process in the background. This depends on server configuration and supported PHP settings.
4. Limitations and Recommendations:
• This option is ideal for websites with low traffic, as on-demand archiving consumes additional server resources and may increase website loading times.
• For larger websites with high traffic, it is recommended to automate archiving via cron jobs to ensure better performance

When the option “Enable archiving via HTTP requests” is disabled in the Matomo WordPress plugin, it changes how Matomo processes and updates reports. Here’s the technical implementation and what happens:
Technical Implementation When the Option Is Disabled
1. Disabling Browser-Based Archiving:
• Disabling this option corresponds to setting MATOMO_TRIGGER_BROWSER_ARCHIVING=false in Matomo’s configuration. This prevents HTTP requests (e.g., from users accessing reports) from triggering the archiving process.
2. Switching to a Cron Job:
• Instead, a cron job must be set up to perform archiving regularly. This is done using the CLI command console core:archive. An example cron job would look like this:
5 * * * * /usr/bin/php /path/to/matomo/console core:archive --url=http://example.org/matomo/ > /dev/null

  • This ensures that archiving runs automatically and independently of user requests.
    3. Asynchronous Archiving (Optional):
    • If the server supports asynchronous archiving, Matomo can use this mode to archive reports in the background. Support for asynchronous archiving can be checked in Matomo’s diagnostics.
    4. Configuration Adjustments:
    • Additional settings can be made in the config.ini.php file under General to further customize behavior, such as:
    browser_archiving_disabled_enforce = 1
    This ensures that archiving is exclusively triggered via cron jobs or CLI commands and not by HTTP requests.
    Implications
    • Performance Benefits: Disabling HTTP-based archiving reduces server load, especially for high-traffic websites.
    • Manual Setup Required: A functioning cron job must be configured; otherwise, no updated reports will be generated.
    • No Real-Time Data: Reports are only updated at intervals defined by the cron job.
22

try to output to stderr

1 Like
23

I have a version that increase the memory to the cli also, with a UI and we set the php error to /stderr

ghcr.io/stephdl/lamp:memoryslider

1 Like
24

Thanks, looks good so far, memory_limit changed from UI works and php shows errors in CLI.
I hope we can catch the error now…

root@lamp:/# php -i | grep memory_limit
memory_limit => 1024M => 1024M
root@lamp:/# grep -r memory_limit /etc/
/etc/php/8.3/apache2/php.ini:memory_limit = 1024M
/etc/php/8.3/cli/php.ini:memory_limit = 1024M
root@lamp:/# php -i | grep error_log
error_log => /dev/stderr => /dev/stderr
error_log_mode => 0644 => 0644
opcache.error_log => no value => no value
root@lamp:/# php error.php
[23-Jan-2025 14:34:48 Europe/London] PHP Fatal error:  Uncaught Error: Undefined constant "produceerror" in /error.php:2
Stack trace:
#0 {main}
  thrown in /error.php on line 2

EDIT:

I tested running the CronArchive php from CLI.
Maybe the Matomo CronArchive cronjob needs to define the memory limit similar to Nextcloud?

Starting with memory limit produces no output (means no error) whereas starting without throws an error:

root@lamp:/# php -d memory_limit=512M /app/wp-content/plugins/matomo/app/core/CronArchive.php
root@lamp:/# php /app/wp-content/plugins/matomo/app/core/CronArchive.php
[23-Jan-2025 14:53:54 UTC] PHP Warning:  Failed to set memory limit to 0 bytes (Current memory usage is 2097152 bytes) in Unknown on line 0
1 Like