I scanned all forum and I dont solve this problem. In my “/public_html/files/usageStats” folder there isn’t any ScheduledTaskLogs folder. Like this:
And archive, processing, reject and stgaes folders are empty. But there are a lot of files in usageEventLogs folders. And these files begin when we update the ojs system from 2.4.2 to 2.4.8.1.
Really I searched the whole forum and all web but I didnt find the core problem and solution. When we upgrade system I think we forgot something. And I learned that it’s too hard and professional to upgrade system.
Also I want to add addition information. In main folder, there is an error_log but it doesn’t work. In error_log there is no information after upgrading.
I began this subject from statistics problem and I learned that when system doesnt produce log files unfortunately there isnt any statistics information.
This is my published article’s editing page.
The views is zero (0). From 2015 this articles views 0 times.
Thanks a lot and I think that this is a critical problem after upgrading system.
Yes, in 2.4.3 the new statistics framework was introduced, please read this document: https://pkp.sfu.ca/wiki/index.php?title=PKP_Statistics_Framework.
Thus, with the upgrade, the old views should be saved in the DB table metrics and accessible via Reports.
The galley views, that are 0 in your installation, display the new statistics now.
It seems like the new statistics plugin is enabled and collecting statistics (in the folder usageStats/usageEventLogs), but it seems that the statistics log files are not processed. Therefore you would need either a cron job or Acorn plugin – rather the cron job than Acron plugin, if possible. The statistics log files would then be processed daily, the numbers would be saved in the DB table metrics and log files moved to the usageStats/archive folder.
The folder scheduledTaskLogs is in the files folder, not usageStatis folder.
I assume that all the log files are there, so that you can still process the files and get the new statistics, from the upgrade on.
Thus, regarding an upgrade, I would suggest to always first consider what changes the new versions are bringing…
You will have to somehow access your DB, with some DB client tool, e.g. phpMyAdmin. There you should be able to see the DB tables and also the table metrics. Also, there is a DB table scheduled_tasks, maybe to take a look there too to see if there is “UsageStatistics” entry there.
Could you find your scheduledTaskLog folder in your file folder and are there any log files starting with “UsageStatistics…” there?
Lets first see all that and then we will maybe know something more… (why the usage statistics log files were not processed…)
Edit: there is nothing strange concerning OJS in your error log file…
Yes, so actually everything seems to be OK with the old views i.e. the old views are migrated correctly
Now, I am just not sure why the new usage statistics logs are not processed :-
Do you see any row in your metrics table that contains metric_type = ojs::counter?
Hmmm… Could you maybe manually create the folder “scheduledTaskLogs” in your file folder and give it the right access permissions, so that the web user can write to it?
Then you could delete the row containing “UsageStatsLoader” from the DB table scheduled_tasks and call/open the journal home page in the browser – this should start a new scheduled task for usage statistics, to process the files.
Check then if the new entry in the DB table scheduled_tasks containing “UsageStatsLoader” appeared again (i.e if the scheduled task was executed) and if there is any log file in the new scheduledTaskLogs folder. Check also if any new error appeared in the error log file.
Oh! Its very good. Thanks to God! The log system is working anymore. Thank Bozana. [quote=“bozana, post:12, topic:28963”]
Then you could delete the row containing “UsageStatsLoader” from the DB table scheduled_tasks and call/open the journal home page in the browser – this should start a new scheduled task for usage statistics, to process the files.
[/quote]
At the end I deleted the “UsageStatsLoader” from the DB table. And system begins to work. Henceforth journal statistics will be healthy.
I think this is a case study. If someone lives like this trouble, this will be a lecture.
So @BMIJ, were the log files processed and moved to the archive? And do you see the statistics in the DB table metrics with type = ojs::counter?
Glad that it worked!
Best,
Bozana
Not yet. But the whole log files now in stage folder. First log files that shows first date after upgrade is now in process folder. I think process will take time. After few days I will write the reseults.
Hi bozana. My log files now working. Also scheduledTaskLogs folder is not empty. Usagestatisticsfileloadertask- log files can be created by system. However I noticed that Usagestatisticsfileloadertask gives warning like:
http://bmij.org
[2017-02-28 09:20:04] [Notice] Task process started.
[2017-02-28 09:20:04] [Error] The directory /home/bmij/public_html/files/usageStats/processing is not empty.
This could indicate a previously failed process, or a concurrently running process.
This file will be automatically reprocessed if you are also using scheduledTasksAutoStage.xml,
otherwise you will need to manually move any orphaned files in the processing directory back into the stage directory.
I saw that the usage_events log file transferring from usageeventlogs folder to stage folder. One usage_event log file is transferring from stage folder to processing folder. But archive folder is still empty. In processing folder log file’s date is first date after upgrade. Th same log file still wait in processing file during three days. I think there is a problem in processing duration. Log files must come from stage to process and after processing tarnsfer to archive mustnt they?
Hmmm… yes, first the files are copied from usageEventLogs to stage (with auto stage function, which should be the case when using the Acron). Then a file is copied to processing, for processing. If an error occurs, depending on what happened, the file is either moved to reject or to stage again. If everything was correct, and the metrics inserted into the DB, the file is moved to archive.
Maybe you could test file by file: remove all other files somewhere else, and leave only one file with the current date and an old file in usageEventLogs. Remove also all UsageStatistics… log files from the folder “scheduledTaskLogs”. Then remove the “UsageStatsLoader” from the DB table “scheduled_tasks” and access the journal home page to start the scheduled task. See then in the scheduled task log file, also in the server error log file, if you can find any helpful information.
