Hey guys,
Some of my tasks are not running as scheduled, but just some of them:
It seems like some of them are only running when the containers are restarted.
UPDATE: If I run the tasks via URL I get this:
Task already runningTask already running
Email Notifications
Email Notifications
Done
Maybe the tasks that are not firing are just stuck?
UPDATE ON UPDATE: I just deactivated all of the tasks, but then I get this…
Daily Maintenance
Import Layouts
Not Required.
Tidy Logs
Done.
Tidy Stats
Done.
Tidy Cache
Done.
Purge Expired API Tokens
Done.
Wake On LAN
Done
Build Layouts
Done
Tidy Library
Done
Email Notifications
Email Notifications
Done
WHAT?!?
RESOLVED: Apparently deleting then recreating all of the tasks and truncating the stat table fixes everything. I suspect that the months of built-up stats might have been too much for XTR to handle, but I’m thankful for whichever thing fixed it.
Thank you for coming along with me on this journey.
1 Like
Apologies that we didn’t reply to you over the weekend (and yesterday UK bank holiday), it could be possible that too many stats records caused this problem, in any case I’m glad you got it working now.
If it would become an issue in the future, please create a new topic for it and we will see what we can do to help you troubleshoot it.
We have noticed this happening and will revisit the way XTR works to see if we can improve it.
I have removed and recreated all the task. If I try to start them manually, they never run. All of them now show the “Next Run” time as the current date and time. If I refresh, the “Next Run” time shows the current time and date.
I tried to enable logging, but nothing is logged. 
Any other ideas on how to fix this? I am sure my stats table is huge by now.
We are still unable to get the task to run. We have the maintenance task running using cron on our server. However, we do not know how to trigger the cleanup of statistics, CMS notifications, or cleanup of audits. Does anyone know how to trigger these? I tried the documentation, but I don’t see it in there.
The behavior that I saw was the stats task blocked the others. As a workaround I would try removing (not disabling) the stats archive task so that the others can run. If that doesn’t work you’ll need to create new tasks for everything and delete the old ones.
Brodkin,
Thanks for the reply and suggestion. However after deleting and re-adding the task, there is no change for us.
Sorry to hear that. Just to be clear, don’t add the stats task back–it’ll kill the others unless you care to truncate that table. I was just hoping to get the rest of your tasks running again.
I appreciate that. When I deleted the task, I figured the stats table might be the issue, so I created just the Clear Notifications task. Tried to get that to run, and nothing. I then created the others with the Stats being last. Still no joy.
The notifications task might be another long-running item, like the stats archive, maybe omit that as well? I’m thinking you start with just the maintenance tasks and go from there.
Maintenance I can get to run calling it manually. Only takes a few seconds. If I have the CMS call it, it never runs. Same for all the other task I want the CMS to run.
If your tasks are marked as running, but they aren’t actually running, then they won’t be run again. You can clear the running status by editing the task, disabling it and then re-enabling it - no need to delete the task and re-add it.
As to why they don’t run - I am assuming it is because they are stuck in the running state?
As @brodkin says, one task taking a long time can effect the other tasks - we need to revisit this to see how we can improve it.
As a workaround, you can run tasks directly from the console by calling run.php <taskId>
@dan, is there currently a limit to the number of rows that the archive tasks process on each run? Also, does the system degrade gracefully if a row fails to be processed?
Stuck in scheduled to run state, As far as I can tell they never even start. None of them from within the CMS. I have tried disabling, deleting and recreating. Nothing seems to work for me. The ones that seem to run are the ones covered by calling the maintenance script from the URL, and only that way.
Thank you Dan for the tip on running them from the console, I will look into that.
There isn’t a row limit - there is a period limit. We didn’t want to be in a situation where the stats export is split over 2 - or more - files.
If it fails, it will try to archive the same period again.
Odd - i’ve not seen a flat out refusal to run before. What happens if you call php bin/xtr.php manually instead of with CRON?
CMS is within Docker. I have not configured the direct access to the CMS files from the host. If I get some more time, I think I can make that happen. Will post back once I have the time on that.