Upgrade to OJS3.0.2 last week, and just noticed that stats do not seem to be logging anymore.
In the metrics table, there are no entries for usage_events_*******.log files since the upgrade.
The archive directory in “/usageStats/archive” has no new files since the upgrade, and processing/reject/stage are all empty.
The actual reports produced views>statistics>view reports etc do not show any stats since the upgrade.
The ‘generate custom report’ button just loads a page with a spinner after clicking.
I also activated the Usage Stats plugin for one journal the other day. After activating this, a new ‘PKP Usage statistics report’ appeared in statistics, and the ‘generate custom report’ button actually then loaded. No new usage_events_*******.log files appeared in the metric table the following day (or after manually activating the job), but there were files now in “usageStats/usageEventLogs” directory.
What would cause the logs in “usageStats/usageEventLogs” (which are now there since activating the plugin) to not be processed/transferred into the metrics table (and “archive” directory?)?
I’ve checked the “scheduledTaskLogs” directory and it is reporting no errors since activating the plugin (before that it said the plugin was disabled).
I’ve read issues with this surrounding base_urls, but I only have one base_url defined in my config.inc.php. No issues with trailing slash or http/https.
I have also ran just the scheduledTasksAutoStage.xml job, but this doesn’t do anything either…the log for that job in “scheduledTaskLogs” just says the task process started then finished. It doesn’t process the files in “usageStats/usageEventLogs”.
I have checked and the acron plugin is enabled site-wide (and individually for each journal just in case)
Ok I think I’ve cracked it, will see tomorrow. I removed ‘plugins.generic.usageStats.UsageStatsLoader’ from the ‘scheduled_tasks’ table, and then manually re-ran the schedule tasks cron via ‘php tools/runScheduledTasks.php lib/pkp/plugins/generic/usageStats/scheduledTasksAutoStage.xml’.
Files moved to the archive directory, and the metrics table now has stuff from yesterday in it!
Will check tomorrow to make sure it’s definitely working again.
Spoke too soon. Removing that row from the database and running the scheduled tasks manually yesterday did work, but the job hasn’t fired again for clearing out yesterdays logs. Will keep an eye on it today.
Hmmm… There are a few fixes since 3.0.2, so why do you not use the most recent OJS version?
It seems like your Acron plugin is not working properly…
Acron plugin is responsible for starting that scheduled task. And this happens i.e. is triggered when you access either the journal home page, an issue TOC page or an article or galley page.
Maybe one more thing you could double check are the access permissions on the whole usageStats folder. Then maybe to test it again, to see if the Acron plugin is working as it should:
– remove the entry plugins.generic.usageStats.UsageStatsLoader from the DB table scheduled_tasks
– check that the current log file is in usageStats/usageEventLogs and that it looks correct
– watch the server php error log file
– call an article page (which should trigger the Acron plugin and it should start the scheduled task)
– what happened? Is there a new entry plugins.generic.usageStats.UsageStatsLoader in the DB table scheduled_tasks? Is there any error in the server php error log file? Is there a new usage stats scheduled task log file in the folder scheduledTaskLogs, with that appropriate timestamp? Is there any error there?
Re: using version 3.0.2…the wheels of Higher Education turn slow, and the upgrade on our DEV system started when 3.0.2 was released, but by the time it got to TEST, then PROD, later versions were released. We couldn’t change the version to latest one as a full round of integration and user testing would have had to start again!
OK so I tried the suggested above, and deleted the required scheduled_tasks table row, then re-loaded a article page whilst watching the logs.
No errors of worth in the php error logs…just lots of strict errors, and a fatal error for trying to parse a LESS file, so unrelated to this issue.
The scheduled task did fire and yesterday’s logs were parsed and added to the metrics table, then moved to the archive directory. The scheduledTaskLog for that day looked like:
[2018-03-28 15:48:50] [Notice] Task process started.
[2018-03-28 15:48:51] [Notice] File /usr/local/ojs/files/usageStats/processing/u
sage_events_20180327.log was processed and archived.
[2018-03-28 15:48:51] [Notice] Task process stopped.
The row was auto-added back into the scheduled_tasks table too, with a correct date-time.
It looks like the acron job is working OK, but doesn’t run any time there is already a plugins.generic.usageStats.UsageStatsLoader row in the table:thinking:
How does the stats task calculate whether to run or not? Should it run as soon as the current day has passed? Or is it calculated somehow on the last_run date from the scheduled_tasks table ?
Yes, in the plugin_settings, plugin_name = acronplugin and setting_name = crontab, all the scheduled tasks are saved that Acron plugin will start. There is also the scheduled task frequency there. UsageStatsLoader should be executed daily. Then it will be checked when that task last_run and if a day passed since then, it will run the task.
So maybe you can check that by accessing an article page again tomorrow e.g. at 7pm.
@bozana lease help me, I also get error like that but only in DB “metrics” not updated, in folder “usageStats/usageEventLogs” files are updated. so the counter view article and downloads is not updated ?
