Closed atom-box closed 1 month ago
The user had a second Matomo instance, on Matomo 4. But now they report this:
We've had the same behavior on the 2nd instance since the matomo 5 update on Friday night.
As already mentioned internally we need more details to reproduce the issue.
Just using nohup
or running the archiving via crontab
should not output "0 out of x archivers". It should always at least find itself and display a positive number (at least 1).
Without more knowledge of the system it may be impossible to reproduce (and fix) it.
I sent a message to the person who discovered this issue.
The user found a workaround as follows:
We found a « solution » for this issue : no more problem since we use php-fpm (fpm-fcgi) and no Apache php module (mod_php).
The problem is still there in matomo 5.1 with mod_php
We didn't have this problem before matomo 5 and with mod_php
Closing as duplicate of #22508, as the other issue contains more detailed information about the actual problem.
What happened?
You can run 4 or more crontabs of the following command, simultaneously, in parallel, Matomo doesn't try to stop you:
core:archive --no-ansi --no-interaction --concurrent-archivers=3 --concurrent-requests-per-website=4 --max-archives-to-process=200 --disable-scheduled-tasks --force-idsites=11
What should happen?
When attempting to start too many archivers, here is the expected message:
How can this be reproduced?
For core:archive:
Here is the syntax used by the person who reported this problem:
core:archive --no-ansi --no-interaction --concurrent-archivers=3 --concurrent-requests-per-website=4 --max-archives-to-process=200 --disable-scheduled-tasks --force-idsites=11
Notice the log output below. You can see that four archivers start up, each reporting that 0 of 3 are running.
(In the private Jira version of this ticket I have included more information. The user says that before upgrading to Matomo 5, this bug did not occur in Matomo 4)
Matomo version
5.0.1
Server operating system
Linux
Relevant log output
Validations