Default Workflow Scheduler no longer working

I see there are a number of older posts - but they don’t seem to have the final solution.

My scheduler seemed to stop working more than a month ago but I haven’t noticed it.

Hey @CleanSweep,

Any chance cron has stopped running?

Hi Mac-Rae

Yes, i just checked it again. not running as root, which I saw on another post.

Is it something to do with the user perhaps?

Have you tried rebuilding schedulers (Admin -> Repair)?

I’ve seen this occasionally. One time i digged further, and for us the reason was that one of the schedulers (can’t remember which) had gotten stuck and didn’t mark itself as finished, causing later iterations to wait endlessly for it to finish. Rebuilding fixed it for us. IIRC the Scheduler’s detailview was similar to yours.

Doesn’t appear to have done anything. thanks for the idea. I checked the backend DB as well and every job is marked as finished. They all have the same end time - so it leads me to believe something happened at that time.

I have seen questions on permissions.

Permissions are 755 for all except the following which are 775
Cache
custom
data
modules
themes
upload

and
suitecrm.log is 644

should php.ini be 775?

I did
php -f cron.php

It ran the jobs - kind of but still didn’t mark it as run.

I fell like I am keeping a diary for everyone :wink: but hopefully it helps someone else if I get to the bottom of this.

The DB now says failure for both jobs with the message

Unexpected failure, please check PHP logs and suitecrm.log

I checked suiteCRM.log on debug (from Mark) and nothing is reported. Where would the php log be?

Without from mark, I found this in the log

Tue Nov 10 10:30:01 2020 [456014][87a8e0a8-9314-5cc9-0b72-5f68b70df16d][DEBUG] Hook called: ::server_round_trip
Tue Nov 10 10:30:01 2020 [456014][87a8e0a8-9314-5cc9-0b72-5f68b70df16d][DEBUG] Calling MySQLi::disconnect()
Tue Nov 10 16:30:02 2020 [456251][-none-][DEBUG] current_language is: en_us
Tue Nov 10 16:30:02 2020 [456251][-none-][DEBUG] Found cache backend SugarCacheRedis

It looks like some are reported in my timezone (America/Winnipeg) and some are in another (possibly UTC?) I can’t change my webserver and it reports back as UTC. Would this be causing the issue?

Is that the Scheduler’s ID? Those two lines don’t really help much, although I think I saw exactly the same lines some time Schedulers stopped working. Too bad I can’t remember what I did to solve it. You should check server logs.

If you’re using apache, some errors are logged in web server’s error log, but more detailed logging usually requires you to enable logging and setup logfiles in php.ini.

No, that is not the scheduler’s ID.

I changed the SuiteCRM timezone to UTC to match the webserver, so it is in queu for now, waiting to catch up to UTC time. I’ll see what happens in a few hours.

So the timezone didn’t make any difference. I’m running out of ideas.

Wed Nov 11 23:05:16 2020 [70925][1][FATAL] Job 4520b245-91ed-8c00-2ee0-5fac6e71dcb5 (Process Workflow Tasks) failed in CRON run

This is the issue - but I can’t get anything out of it. I’ve rebuilt the scheduler twice now.

Ok - so long story - but I found out one of my workflows is causing the issues. I turned them all off and it ran fine. I then turned some on in batches. I’ve narrowed it down to a few workflows that all seem to cause the workflow scheduler to fail. If I mark them as inactive, the process completes without failing - if I activate any of the three workflows, the workflow process fails. I will need to continue debugging.

1 Like

Is there a maximum number of files a workflow can change? I put conditions on the workflows that were causing issues, to limit the number of files - and it runs no problem. I must have reached a maximum number of files in the last month and then it stopped running.

Assuming there is a maximum - is there a way to change it?