Actualmente tenemos un problema en el OJS que manejamos dentro de la Universidad Autónoma de Aguascalientes con respecto al conteo de vistas y descargas de las 15 revistas visibles dentro del portal https://revistas.uaa.mx/.
En todas, desde el día 12 de enero de 2024, dejaron de aparecer las cifras dentro del apartado de “Estadísticas” y el subapartado de “Artículos”, lo cual nos ha generado problemas para los informes que debemos entregar desde la Editorial de la universidad. Las gráficas marcan 0 en todas las revistas (adjunto captura de pantalla) y nosotros apenas lo notamos el pasado 20 de marzo, de modo que pedimos apoyo al departamento institucional de Redes de la UAA, pero no nos han dado solución. Consultamos algunas entradas del foro con conflictos similares y se las proporcionamos a nuestros compañeros de Redes, pero tal vez no han intentado abordar el problema desde allí y esperamos que la respuesta a esta consulta sirva para guiarles en la atención a la falla.
La versión de OJS que tenemos es la 3.3.0.14 y fue actualizada apenas el 26 de julio de 2023. ¿Pueden asesorarnos por favor con este problema?
¡Gracias por su apoyo! Estoy pendiente en caso de que sea necesario proporcionar más información.
Can you see where, in which folder, are the usage log files from 12.01.2024 on? – Take a look in your files folder on the server, in the folder usageStats/. The log files (with the name e.g. usage_events_20240112.log) should be in one of the subfolders there.
For the moment, I passed the information to the institutional staff who can look up in which folder those files are located, because i can’t access that part. As soon as they give us information, I will reply again.
Lo que te indica @bozana en su respuesta es que la falta de esa información está relacionada con los archivos de uso que guarda OJS y que luego procesa para generar las estadísticas …
Los archivos que guarda diariamente OJS están dentro del directorio ‘files’ de OJS (para saber dónde está ubicado tenés que revisar el archivo de configuración del sistema ‘config.inc.php’) en un subdirectorio de nombre usageStats
Ya se revisó en el contenido del último directorio y sí, efectivamente están los archivos no procesados a partir del 12 de enero en adelante, hasta hoy. ¿Qué procede hacer?
You should see where those files are, in which folder.
If they are in reject folder, you would need to see the scheduled task logs (in files/scheduledTaskLogs/, then the Usagestatisticsfileloadertask... file from the next day) to see why the log file processing failed.
Also, the server PHP error logs could contain some errors that can help find the reason.
It would be good if a technical person, who have access and manage the OJS installation, would join this chat.
Agregando a lo que bozana indica más arriba … Si no hay nada en el directorio reject que indique una causa para que dejaran de procesarse las estadísticas de uso
Una consulta … el módulo Acron está habilitado en forma global en OJS?
De lo contrario, debería haber una tarea programada en el sistema que soporta OJS que dispare el procesamiento de esos archivos
En nuestro caso, se trata de una tarea configurada mediante ‘cron’ de la siguiente :
Solución rápida para mantener a los editores calmados … copiar los archivos (mejor empezar por el del día 12 solamente) desde el directorio usageEventLogs al directorio stage y ver si OJS lo procesa. No es inmediato, asi que tal vez ocurra al dia siguiente.
do the usage stats log files with the date > 12.1.24 exist? If they do not exist is the Usage Stats Plugin enabled?
are the access rights for the usage stats log files correct? – they should be writable by the web user
is Acron plugin enable/used or is there a Cron job that runs OJS scheduled tasks?
what is in the database column “last_run” in the database table scheduled_tasks, where class_name = “plugins.generic.usageStats.UsageStatsLoader”?
it would be good to analyze the scheduled tasks log files files/scheduledTaskLogs/Usagestatisticsfileloadertask..., to see which is the last one (from what date) and what is written in a file from a date > 12.1.24
see if there are any errors (that would probably happen/be repeat every day when the usage stats log files are processed) in the server’s PHP error log file
It will help if we could get all the answers on these questions
Here are the answers to the questions tha you indicate from the technical person that help us:
do the usage stats log files with the date > 12.1.24 exist? If they do not exist is the Usage Stats Plugin enabled?
en la carpeta DATOS/ojs3-files/usageStats/usageEventLogs/, existen archivos de usage_events_20240112.log hasta usage_events_20240404.log. Si está activo el plugin Usage Stats Plugin
are the access rights for the usage stats log files correct? – they should be writable by the web user
-rw-r–r–. 1 apache apache 944588 Jan 12 17:59 usage_events_20240112.log
is Acron plugin enable/used or is there a Cron job that runs OJS scheduled tasks?
**Se ejecuta con cron, cada hora ** 0 * * * * php /var/www/html/ojs3/tools/runScheduledTasks.php
what is in the database column “last_run” in the database table scheduled_tasks, where class_name = “plugins.generic.usageStats.UsageStatsLoader”?
it would be good to analyze the scheduled tasks log files files/scheduledTaskLogs/Usagestatisticsfileloadertask…, to see which is the last one (from what date) and what is written in a file from a date > 12.1.24
estos son los archivos que estan en la carpeta scheduledTaskLogs
see if there are any errors (that would probably happen/be repeat every day when the usage stats log files are processed) in the server’s PHP error log file
Although they are too many and repetitive, the technical person is pointing out that two error log files stand out within the PHP server, I guess they are the most recent ones that can be displayed:
[Thu Apr 04 13:12:48.149505 2024] [php7:error] [pid 10044] [client 66.249.65.37:36730] PHP Fatal error: Uncaught InvalidArgumentException: Passed value cannot be an array in /var/www/html/ojs3/lib/pkp/lib/vendor/danielstjules/stringy/src/Stringy.php:45\nStack trace:\n#0 /var/www/html/ojs3/lib/pkp/lib/vendor/danielstjules/stringy/src/Stringy.php(73): Stringy\Stringy->__construct()\n#1 /var/www/html/ojs3/lib/pkp/classes/core/PKPString.inc.php(161): Stringy\Stringy::create()\n#2 /var/www/html/ojs3/cache/t_compile/a95e9f20492587d73a4f35fa465ca6ee809b9709^c2055d14f27582f3361894f4184ce1a4c0497385_0.app.frontendpagessearchAuthor.php(58): PKPString::substr()\n#3 /var/www/html/ojs3/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_66062e031df675_96329792()\n#4 /var/www/html/ojs3/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#5 /var/www/html/ojs3/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#6 /var/www/html/ojs3/li in /var/www/html/ojs3/lib/pkp/lib/vendor/danielstjules/stringy/src/Stringy.php on line 45 [Thu Apr 04 13:17:21.325005 2024] [php7:error] [pid 9758] [client 131.72.0.4:22763] PHP Fatal error: Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘gpdp9q5c76p1haljktna3hkcgj’ for key ‘sessions_pkey’ in /var/www/html/ojs3/lib/pkp/lib/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:119\nStack trace:\n#0 /var/www/html/ojs3/lib/pkp/lib/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php(119): PDOStatement->execute()\n#1 /var/www/html/ojs3/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(489): Doctrine\DBAL\Driver\PDOStatement->execute()\n#2 /var/www/html/ojs3/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(664): Illuminate\Database\Connection->Illuminate\Database\{closure}()\n#3 /var/www/html/ojs3/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(631): Illuminate\Database\Connection->runQueryCallback()\n#4 /var/www/html/ojs3/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(496): Illuminate\Database\Connection->run()\n#5 /var/www/html/ojs3/l in /var/www/html/ojs3/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 671, referer: https://revistas.uaa.mx/index.php/pirocromo/article/view/1156/1112
Unfortunatelly, the errors in the PHP error log file do not help us further…
What is written inside the scheduled task log file Tareadecargadearchivodeestadísticasdeuso-…-20240404.log ?
Do you also have a cron job like this: 0 * * * * php /var/www/html/ojs3/tools/runScheduledTasks.php** /var/www/html/ojs3/plugins/generic/usageStats/scheduledTasks.xml
That means the one for the usage statistics scheduled task? – It seems to be executed correctly, but just to know how they are run…
Hello @bozana, thanks for your support. Here are the answers:
What is written inside the scheduled task log file Tareadecargadearchivodeestadísticasdeuso-…-20240404.log ?
Este es el contenido del archivo:
Do you also have a cron job like this:
0 * * * * php /var/www/html/ojs3/tools/runScheduledTasks.php** /var/www/html/ojs3/plugins/generic/usageStats/scheduledTasks.xml
That means the one for the usage statistics scheduled task? – It seems to be executed correctly, but just to know how they are run…
se ejecuta con crontab 0 * * * * php/var/www/html/ojs3/tools/runScheduledTasks.php
(I still do not know how your UsageStatsLoader scheduled task is executed, because you seem not to have a Cron job for that, but because your Acron plugin is enabled, it is probably executed by Acron plugin. It is also strange that you have a Cron job for scheduled tasks but also use Acron plugin – this could actually lead to some strange behaviors. However the UsageStatsLoader scheduled task execution seems to be OK.)
The strange thing is that you do not have any error or warning in the scheduled task log file
Your usage stats log files are in the folder usageEventLogs/ but they should actually be moved to the stage/ folder once the scheduled task is started/executed. So I am wondering why are they not moved… If moving them did not work there should be an error/warning message in the scheduled task log file. Very strange…
Could you also post the settings of your UsageStatsPlugin?
And maybe what subfolders are in the folder usageStats/ and the access rights for those subfolders.
And you have entries in your usage stats log files, they are not empty? When you access an article page you can see that URL written into the current usage stats log file?
And what do you have in the folder stage/, processing/ and reject/ ?
EDIT:
And when you go to your Usage Statistics plugin > Settings:
is “Create log files” checked?
what do you have for "Parse log files regex "?
do you have “Compress archives” checked?
do you use a salt file – do you have anything in “File path for the anonymizing salt”?
do you collect city or region stats – are the checkboxes selected?
Are the URLs in your log files fully correct? And is the base_url setting in your config.inc.php the same as in the URLs in the log files?
Do you maybe use any rules on the server to change the URLs, or have you set any of these settings in the config.inc.php
