Schedulers never run - 8.0.3

I have a couple instances of 8.0.3 running, one dev and one production. I am trying to get the schedulers running but it is looking like none of the out of the box ones have ever ran.

Linux (Apache) server

Added CronTab user per requirements, confirmed folder permissions set to 775, checked config - allowed cron users and that’s correct. What else may be the cause? Cron is running on the server itself (manages backups) so adding the cronTab to call the cron.php file is all configured, but something is still missing there.

Looked through docs and other posts and haven’t found anything to direct me in next potential things to check so here I am!

What exactly did you put in crontab? Did you point it to public/legacy/cron.php?

Which user is that crontab spawning processes for?

Yup -cron is
public_html/public/legacy; php -f cron.php > /dev/null 2>&1

confirmed user is correct as well from system diagnostics.

Hi @jkortus1234 .
.
As you already added your web server user’s crontab file, file permissions and ownerships, I would troubleshoot by running the cron.php manually.
.
I would go to admin >> schedulers >> Process Workflow Tasks
in order to see the “LAST SUCCESSFUL RUN”.
.
Then I run this command at /public/legacy:
$ php -f cron.php
.
Then I go back to admin >> schedulers >> Process Workflow Tasks
and check the “LAST SUCCESSFUL RUN”.

1 Like

That command is missing the cd in the beginning.

On some systems php executable is not in the path, so you need to add a full path there, something like:

cd public_html/public/legacy; /usr/bin/php -f cron.php > /dev/null 2>&1

Apologies, yeah the full path with cd is in there already…

*    *    *    *    *     cd /home/jfraner2/public_html/public/legacy; php -f cron.php > /dev/null 2>&1 

is the full string for the cron job

Was able to run the cron.php file from terminal and it worked… so what would be missing between the CronTab on the server and that cron.php file? … Maybe I missed a permissions some place? Is there a definitive list of what permissions should be set on what files/folders?

That’s good news.
.
As a test, I would try this out in /public/legacy/config.php

    'allowed_cron_users' => 
    array (
        0 => 'www-data',
        1 => 'crontab username',
    ),
Save changes.
.
As an additional layer, in Admin >> Repair >>  select: Quick Repair and Rebuild
.
Then go back to admin >> schedulers >> Process Workflow Tasks
and check again the “LAST SUCCESSFUL RUN”.

If the allowed_cron_users was blocking you, there would be a message about it in suitecrm.log

Anyway, it would be great to check both your logs - suitecrm.log and php_errors.log

It’s possible that crontab is doing it’s job, firing up cron.php, and you’ll see signs of that in the log. Then maybe something is breaking it a bit afterwards. SuiteCRM starts going through the list of Scheduled jobs and maybe one of them is hanging the rest of the execution.

nada… only instance of the scheduler being called is from the one I manually called it from terminal. Nothing since, no changed times on last run.
Leaning back towards permissions somewhere as the next step… 775 right? data, cache, custom, themes, upload, config_override.php… any others?

Did you try the full path to the php executable as I suggested above?

Another suggestion is to try it first with a job like this:

*    *    *    *    *     whoami >> /tmp/helloworld.txt 

And see if that file gets created in /tmp directory, and which user name it contains.