Scheduled tasks have stopped processing usage logs

Thanks for your conversation so far. I have followed the discussion and read instruction on how to process log files Statistics

However, I still don’t know how to fix the issue we have. I checked our files directory usageStats folder, and I see all of the logs since 1st Sep this year are in the stage folder, and usage_events_20200831.log in the processing folder. Nothing in the reject folder , and the usageEventlogs folder the recent two days (today and yesterday) log files. So it appears that the scheduldedtask has stopped working on 31 August.

We have the following error message when I checked usagestatisticsfileloadertask on 1st sep onwards file:

[Error] The directory F:\journals-attachments\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 have checked and the Acron Plugin is enabled.

How can re-activate the scheduled task?

thanks in advance,
Yanan

HI @Yanan_Zhao,

I’ve split your post off from the other thread so that it is easier to discuss the problem you’re facing.

Have you tried moving the usage_events_20200831.log file out of the processing folder and into the stage folder, and then running the scheduled tasks again? The error message suggests that this might be enough to get it working again.

Hi, Thanks. I have moved it out of processing folder and into the stage folder and waited for 48 hours. however, when I checked it this morning, the usage_events_20200831.log file is stuck back in the processing folder again.

Do you have any idea how to proceed from there?

Yanan

hi, you don’t need to wait 48 hours, Actually, log processed in 24 hours.

log processed daily stored scheduledTaskLogs

image

Open the last log (by date) and you will see when log processed.
image

if this log is empty or no process its mean your scheduled not work.

@NateWr - do you have any further idea? my latest log showed the same error message as mentioned above.

[2020-12-01 20:21:20] https://journals.lincoln.ac.nz
[2020-12-01 20:21:20] [Notice] Task process started.
[2020-12-01 20:21:20] [Error] The directory F:\journals-attachments\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.

Thanks in advance.
Yanan

would you like to open scheduledtasklogs file Userstatisticfileloadertask …20201201.log and we try to see what happen in there?

Hi @Yanan_Zhao,

It sounds like something may be interrupting the processing while it is happening. I’d recommend doing the following:

  1. Move the log out of processing into staged.
  2. Update your database by changing the last_run column in your scheduled_tasks table for the usage stats row. Set it to some old date so that it will run the next time you load your backend.
  3. Load the backend in your browser.
  4. Check to see if the file has been moved into processing.
  5. If it has, check your server’s error log to see if there is a fatal error that is ending the process early.

Thank you for your reply. Can I please confirm with you that it is the following row (highlighted in yellow) you have suggested to set to an old date?

Capture

When you say ‘load the backend’, what do you mean by that? Sorry can you clarify what’s ‘backend’ you are referring to?

Thanks,
Yanan

Yes, that’s the right row. You want to set an older date so that the scheduled task thinks it needs to run again. Usually more than 24 hours ago is enough.

When you say ‘load the backend’, what do you mean by that?

Anywhere in the editorial interface, for example the submissions lists. This will ensure the acron plugin kicks off the scheduled task. You can see if it ran by checking that row in the database table again to see if the last_run date is updated.

Thanks for the reply. I really appreciate your help. I have followed your steps above (i.e., moved the log out of processing into stage, updated the time stamp to 48 hours earlier, reloaded the backend in the browser, I can see the log file has been moved back into the processing folder). I then found the following php error message. Any idea how I can fix it?

PHP Fatal error: Call to a member function getGenreId() on null in F:\journals.lincoln.ac.nz\wwwroot\plugins\generic\usageStats\UsageStatsLoader.inc.php on line 78
PHP Warning: assert(): DefaultOverrideHeaderChildThemePlugin failed in F:\journals.lincoln.ac.nz\wwwroot\lib\pkp\classes\plugins\PluginRegistry.inc.php on line 228
PHP Warning: assert(): DefaultOverrideHeaderChildThemePlugin failed in F:\journals.lincoln.ac.nz\wwwroot\lib\pkp\classes\plugins\PluginRegistry.inc.php on line 228
PHP Warning: assert(): DefaultOverrideHeaderChildThemePlugin failed in F:\journals.lincoln.ac.nz\wwwroot\lib\pkp\classes\plugins\PluginRegistry.inc.php on line 228
PHP Warning: assert(): DefaultOverrideHeaderChildThemePlugin failed in F:\journals.lincoln.ac.nz\wwwroot\lib\pkp\classes\plugins\PluginRegistry.inc.php on line 228

This seems to be the same error message for another issue I’m trying to solve on Error message when downloading View report - #9 by asmecher

Since these two issues are all related to usage stats, it may be caused by the same data problem?

Yanan

Yes, this is likely the cause of the same problem. Try running the fix that Alec suggested in that forum post, and then try to process the logs again.

Thanks. I am quite new to SQL and OJS, so still not quite sure How I can update the genre IDs. I will reply to Alec from the other forum post.

@NateWr - Hi sorry to bother you. Just wondering if you can give an example query on how ot update the genre IDs? Thanks.