OJS 3.5.0‑1 – Usage stats logs stuck in dispatch, UsageStatsLoader finishes “DONE” but no metrics are generated

[Thelurydead]

I’m having an issue with OJS 3.5.0‑1 where usage statistics are not being updated.

Main symptom

• Article and issue statistics remain at 0, even though the journal is being visited.

• The usage stats pipeline does not complete: log files are moved into usageStats/dispatch, but no new files appear in usageStats/archive and no new metrics are written to the database.​

usageStats directory structure and behaviour

• usageStats/archive: contains only older log files (e.g. up to a certain date such as 22/12). No new log files have been moved here since that date.

• usageStats/dispatch: contains many usage_events_YYYYMMDD.log files (including recent days) that never leave this directory.

• usageStats/usageEventLogs: contains only today’s file; files from previous days have been moved to dispatch.

• The other directories (processing, reject, stage) are empty or show no recent activity.​

• File permissions under usageStats allow the PHP user to read and write.​

Task scheduler / jobs

• The task scheduler is enabled and appears to be working.

• When I run:

  bash
  

  php lib/pkp/tools/scheduler.php test

  it offers APP\tasks\UsageStatsLoader in the menu.

• Running it produces output like:

  bash
  

  ┌ Qual comando você gostaria de executar? ─────────────────────┐
│ APP\tasks\UsageStatsLoader │
└──────────────────────────────────────────────────────────────┘

  Running [APP\tasks\UsageStatsLoader] ........................................ 5–8ms DONE

• The job finishes with status DONE in a few milliseconds, but no files are moved from dispatch to archive and no new metrics appear.

Temporary table usage_stats_total_temporary_records

• The table exists and is currently empty:

  sql
  

  SELECT*FROM usage_stats_total_temporary_records;
-- returns 0 rows

• The first column is:

  • usage_stats_temp_total_id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT

  • It is the primary key and has AUTO_INCREMENT set in the “Extra” field.

• This means my schema does not match the issue where this column was missing AUTO_INCREMENT; that fix is not applicable here.​

• After running APP\tasks\UsageStatsLoader via scheduler.php test, the table still has 0 rows (no temporary records are inserted at all).​

UsageStatsLoader code

• classes/tasks/UsageStatsLoader.php has the following implementation:

  php
  

  namespace APP\tasks;

  use APP\jobs\statistics\CompileCounterSubmissionDailyMetrics;
use APP\jobs\statistics\CompileCounterSubmissionInstitutionDailyMetrics;
use APP\jobs\statistics\CompileIssueMetrics;
use APP\jobs\statistics\CompileSubmissionGeoDailyMetrics;
use APP\jobs\statistics\CompileUniqueInvestigations;
use APP\jobs\statistics\CompileUniqueRequests;
use APP\jobs\statistics\DeleteUsageStatsTemporaryRecords;
use APP\jobs\statistics\ProcessUsageStatsLogFile;
use PKP\jobs\statistics\ArchiveUsageStatsLogFile;
use PKP\jobs\statistics\CompileContextMetrics;
use PKP\jobs\statistics\CompileSubmissionMetrics;
use PKP\jobs\statistics\RemoveDoubleClicks;
use PKP\site\Site;
use PKP\task\PKPUsageStatsLoader;

  classUsageStatsLoaderextends PKPUsageStatsLoader
{
protected function getFileJobs(string$filePath, Site $site):array
{
$logFileName = basename($filePath);
return [
new ProcessUsageStatsLogFile($filePath, $logFileName),
new RemoveDoubleClicks($logFileName),
new CompileUniqueInvestigations($logFileName),
new CompileUniqueRequests($logFileName),
new CompileContextMetrics($logFileName),
new CompileIssueMetrics($logFileName),
new CompileSubmissionMetrics($logFileName),
new CompileSubmissionGeoDailyMetrics($logFileName),
new CompileCounterSubmissionDailyMetrics($logFileName),
new CompileCounterSubmissionInstitutionDailyMetrics($logFileName),
new DeleteUsageStatsTemporaryRecords($logFileName),
new ArchiveUsageStatsLogFile($logFileName, $site),
];
}
}

• This file has not been manually modified.

• VS Code shows a static warning on ArchiveUsageStatsLogFile($logFileName, $site) (“Too many arguments”), but there is no runtime error; the scheduler reports DONE without any PHP error in the logs.

Environment

• Application: OJS 3.5.0‑1.​

• PHP 8.3.

• error_log is empty regarding this task (no notices, warnings, or errors when UsageStatsLoader runs).​

• Cron is configured to call the scheduler regularly; other scheduled tasks run fine.​

Questions

1. Are there any known issues or bugs in OJS 3.5.0‑1 that could cause usage stats log files to get stuck in dispatch and never reach archive, with APP\tasks\UsageStatsLoader finishing as DONE but not inserting any rows into usage_stats_total_temporary_records?​

2. Is there a recommended way to debug the UsageStatsLoader pipeline in 3.5.0‑1 (for example, increasing log verbosity for the jobs/queue system, or running a specific jobs command with more verbose output) to see whether log parsing or job dispatch is failing silently?​

3. Is there a patch or commit in a newer 3.5.0‑x / 3.5.x release that addresses this kind of behaviour in the usage stats implementation, or any documented procedure to re‑process logs with the new jobs/queue‑based statistics system?​

Note: I am a native Brazilian Portuguese speaker, and this text was drafted with the help of Perplexity AI to make sure I can explain the technical details clearly in English

[aalzaidy]

Hello, I had similar issue, So I needed to ensure that the Cron Job is correct. I am using cPanel, and I had to have the full path for the scheduler file my is something like this php /home/YOUR-USER-NAME/public_html/lib/pkp/tools/scheduler.php run >> /dev/null 2>&1

[Thelurydead]

I double-checked my cron job, and it is already using the full absolute path.
In my Panel, it is configured as:
/usr/bin/php /home/MY_USER/domains/MY_DOMAIN/public_html/lib/pkp/tools/scheduler.php run

The cron logs show entries like Running [PKP\task\ProcessQueueJobs] … DONE, so the scheduler is definitely running. Unfortunately, the usage stats issue persists (logs stay in dispatch and no temporary or final metrics are written).

[aalzaidy]

While this seams to look like linux OS I dont know why you have your domain listed, however, because you are sure about the path, did you enabled the task to work from your config.inc.php file your Scheduled Task Settings should be enable make sure task_runner = On

I am not a tech support I am someone like you who keep working until I get it done.

[Thelurydead]

Data after recovery

After further testing, I confirmed that the issue was not related to the cron job configuration or to the config.inc.php settings, but to file permissions on the files_dir.​

To debug, I temporarily set the files_dir permissions to 777 and repeatedly ran the job runner via SSH:

bash

php lib/pkp/tools/jobs.php run -v

I executed this command until there were no jobs left in the queue and all usage statistics log files had been processed and moved to the appropriate subdirectories (archive, etc.).​

Once everything was processing correctly and the statistics were displaying as expected in the dashboard, I reverted the permissions on the files_dir to a more secure configuration by applying 755 to directories and 644 to files. This confirmed that the root cause was insufficient write permissions for the jobs/statistics processing, rather than a problem with the cron job itself.​

I would like to thank you all who reached out and offered suggestions

[Thelurydead]

Cron jobs: