OJS 2.4.x stoped to process statistics

Software Support
1

Hi,

I spend the whole day with this and I’m starting to get crazy, so any help would be really appreciated.

Problem:

Most of our journals still are on an old OJS 2.4.5 (shame on me)…
All worked perfectly till a week ago (working on the OJS 3.x migration) we update the server and php versions where mixed. After some work to we manage to recover the server (rolling back to php 5.6.40) but statistics are still stuck.

I don’t user anacron (I prefer my own cron to decide the moment I ask my server to do the heavy duty…) so, in my cron, for each journal, I’m making the following calls:

$ php /home/ojs/htdocs/myjournal/tools/runScheduledTasks.php /home/ojs/webdata/myjournal/registry/scheduledTasks.xml     # <--- I ignored this one, because it's not about statistics.
$ php /home/ojs/htdocs/myjournal/tools/runScheduledTasks.php plugins/importexport/crossref/scheduledTasks.xml
$ php /home/ojs/htdocs/myjournal/tools/runScheduledTasks.php plugins/generic/usageStats/scheduledTasksAutoStage.xml
$ php /home/ojs/htdocs/myjournal/tools/runScheduledTasks.php plugins/generic/alm/scheduledTasks.xml

Testing:

To see what really happens I ran the scripts outside the cron and as root (to be sure there was no permission issue)… and all commands run extremely fast (less than a second), without any feedback and don’t show any errors in logs (checked twice and forced an error to be sure I was checking the right log… and I was).

Then I check the statistics folders (at /usageStats/usageEventLogs/)… processing, reject and stage ones are empty, archive is quite full (as expected), but usageEventLogs include log files since last run (20200714).

If I check the “scheduled_tasks” table, all are from one week ago, except for the script I ran manually that looks fine to me:

plugins.generic.usageStats.UsageStatsLoader 	2020-07-21 17:46:56

If I check the “metrics” table, last row it’s also from one week ago:
usage_events_20200714.log 260 1 65 730 518 20200714 202007 2 US 0 San Francisco ojs::counter 1

As is explained in some post of this forum, I confirmed the existence os “GeoLiteCity.dat” in the plugin’s folder and is fine.

The error look congruent with this patch from Bruno’s so I apply it… but nothing changes.

I really don’t know what else to check… except start tracing the code, so any help is really welcome.

Thanks a lot in advance,
m.

PD: Old documentation about this, could be found here.
For new documentation, check this

2

What do you see in recent Usagestatisticsfileloadertask-*-2020????.log logs under ‘scheduledTaskLogs’ in files_dir?

3

Thanks a lot for you help Clinton.

Still fighting with this today. :frowning:

More specifically:

$ cd [files_dir]/usageStats && tree
.
├── archive
│   ├── usage_events_20150113.log
│   ├── usage_events_20150114.log
│   ├── usage_events_20150115.log
  ...
│   ├── usage_events_20200710.log
│   ├── usage_events_20200711.log
│   ├── usage_events_20200712.log
│   └── usage_events_20200713.log
├── processing
├── reject
├── stage
└── usageEventLogs
    ├── usage_events_20200714.log
    ├── usage_events_20200715.log
    ├── usage_events_20200716.log
    ├── usage_events_20200717.log
    ├── usage_events_20200718.log
    ├── usage_events_20200719.log
    ├── usage_events_20200720.log
    ├── usage_events_20200721.log
    └── usage_events_20200722.log

No “scheduledTaskLogs” folder there. I think it was introduced after 2.4.5.

I’m wondering it could be related with the php version… because I’m quite sure nobody tested ojs 2.4.5 with php 5.6.40, as far as this php version didn’t exist when 2.4.5 was released. :slight_smile:

What is killing me is there is no feedback… the script runs smoothly, without any error but does nothing (same way if I don’t pass any xml as an argument). I forced an error in runScheduledTasks.php to see if I was in the right log file and then this error is registered.

4

The “scheduledTaskLogs” folder should be directly off the root of files_dir. It will be parallel to “usageStats”.

5

Sorry, but not in my journals. :frowning:

I confirmed in config.inc.php my files_dir root and this is what I have inside it:

$ tree -L 1
.
├── crossref
├── journals
├── registry
├── site
├── temp
└── usageStats

I checked in 3-4 different journals without success, so I try to “find” and “locate” and found nothing in my storage partition. The only “scheduledTaskLogs” folders I find are in my ojs3 or omp instances.

Does the theory of the php version make any sense to you?
Any idea about how to trace the script to discover why is doing… nothing?

I notice I can call “php tools/runScheduledTasks.php” with any parameter and the result is always the same… script exit immediately without errors or reporting stuff in log. Could this be related with the issue? I mean, a problem parsing the script arguments or something?

Thanks again for everything Clinton. I really run out of ideas here.

6

Maybe is obvious, but I missed to say that, in “Usage Statistics” (journalDomain/manager/plugin/generic/usagestatsplugin/settings) I checked “Create log file” with the default regex… as far as my apache2 not using any custom log format.

7

The intent in both 2.4.x and in 3.x is for these messages (success and failure) to be written to log files in “scheduledTaskLogs”. I would try creating that directory and ensuring the web process can write to it. Then, re-run the usageStats cron. We should get some detail of what is happening.

When creating logs with the usage statistics plugin, the “Parse log files regex” field can/should be empty, since it is using the default log file, rather than trying to read the Apache log file.

If staying within PHP 5.x, I don’t think the PHP version will make a difference. If going to PHP 7.x, only the latest github branches will support that for 2.4.x.

1 Like
8

Followed your indications I created the missing “scheduledTaskLogs” folder and I set the right permissions and ownership to apache2 (www-data)… and still nothing. :frowning:

A screenshot to show it all:

image

What is driving my crazy is getting no error… is a kind of WSD but in terminal mode.

Understood about the “parse log files regex”, but right now I feel is better not touching the configuration till I make all running again.

Thanks for your time Clinton. I’m starting feeling bad for this.

9

Expected function should be something like this:

[files]$ ls
crossref  ezid  journals  scheduledTaskLogs  site  temp  usageStats
[files]$ ls -rtl scheduledTaskLogs/ | tail
-rw-r--r-- 1 apache apache   137 Jul 21 18:38 Openaccessnotification-5f176e4a35d02-20200721.log
-rw-r--r-- 1 apache apache   137 Jul 21 18:40 CrossRefautomaticregistrationtask-5f176e4a93550-20200721.log
-rw-r--r-- 1 apache apache   295 Jul 21 20:38 Usagestatisticsfileloadertask-5f178a6a30117-20200721.log
-rw-r--r-- 1 apache apache   137 Jul 21 20:40 CrossRefautomaticregistrationtask-5f178a6cb11fe-20200721.log
-rw-r--r-- 1 apache apache   137 Jul 22 06:39 CrossRefautomaticregistrationtask-5f18170a517af-20200722.log
-rw-r--r-- 1 apache apache   137 Jul 22 08:38 CrossRefautomaticregistrationtask-5f1833299712a-20200722.log
-rw-r--r-- 1 apache apache   574 Jul 22 10:38 PKPPLNDepositorTask-5f184f499e571-20200722.log
-rw-r--r-- 1 apache apache   137 Jul 22 10:38 CrossRefautomaticregistrationtask-5f184f4a72433-20200722.log
-rw-r--r-- 1 apache apache   137 Jul 22 12:39 CrossRefautomaticregistrationtask-5f186b6a4dffe-20200722.log
-rw-r--r-- 1 apache apache   137 Jul 22 14:39 CrossRefautomaticregistrationtask-5f188789a7dc3-20200722.log
[files]$ cat scheduledTaskLogs/Usagestatisticsfileloadertask-5f178a6a30117-20200721.log
http://anthro-age.pitt.edu/ojs
[2020-07-21 20:38:02] [Notice] Task process started.
[2020-07-21 20:38:04] [Notice] File .../files/usageStats/processing/usage_events_20200720.log was processed and archived.
[2020-07-21 20:38:04] [Notice] Task process stopped.

The logfile from scheduledTaskLogs would be where you would expect to see both success messages and any errors or warnings.

I think my next step would be to connect xdebug or add debugging lines to see how far into runScheduledTasks.php the process makes it.

1 Like
10

Thanks again Clinton.

I started to trace it in the old way (adding error_log calls and tracing the code)… because, (between you and me) I never manage to make xdebug work properly. :frowning:

After a couple of hours I arrived to “function errorHandler()” (in lib/pkp/classes/core/PKPApplications.inc.php) and I forced the function to make errors more verbose (that is wired because the setting config.inc.php parameter’s didn’t show any info) and log start flowing… a LOT.

Mostly where complains about function calls (like “Registry::getRegistry() should not be called statically, assuming $this from incompatible context”), that I assume that are just warnings, but then I noticed a problem with mysql (“Declaration of ADODB_mysql::MetaColumns() should be compatible with & ADOConnection::MetaColumns($table, $normalize = true), /h$
me/ojs/htdocs/ojs-periferia/lib/pkp/lib/adodb/drivers/adodb-mysql.inc.php, line 21”) so I though would be nice to check the php modules to see if all was fine… and were not.

Looks like when I replaced PHP, it didn’t include all the modules I had to make OJS happy (see full list here) so I enabled them and FINALLY I got a fatal error:

PHP Fatal error:  Call to undefined method GeoLocationTool::isPresent() in /home/ojs/htdocs/ojs-periferia/plugins/generic/usageStats/UsageStat$
Plugin.inc.php on line 277

I don’t see much about this error in the forum, but similar errors are reported in github:

Tomorrow I will start checking all the modules, just in case I missed someone.

Thanks a lot for your help Clinton!

1 Like
11

FINALY!! :partying_face: :tada: :balloon: :balloon: :partying_face:

The error about the “GeoLocationTool” was my fault: During this days I tried desperate measures and I one of those was cherry-picking a fix from Bozana’s that was talking about geoip method. Recovering a clean ojs 2.3.5 fixed the issue.

In short, for those that could arrive someday to this pst, there was a problem with the existing php version that don’t include all the required modules.

What is wired is, when processing the logs, OJS don’t throw any error or complains about missing php modules… but we are talking about a very old OJS, so better forget all move to OJS 3 as soon as possible.

Clinton, thanks again for all your help. I debt you a beer (or whatever you like for drink).

12

Quisiera un té con límon, por favor, algún día cuando pudemos viajar otra vez.

1 Like
13

Cuenta con una botella entera. :wink: