Trouble Shooting Workflows

While looking at Admin/Schedulers I saw that the “Process Workflow Tasks” workflow shows that the “Last Successful Run” was 2017-07-04 11:15am

I’ve got the cron set as * * * * * cd /home/fccphil/public_html/crm; php -f cron.php > /dev/null 2>&1 in the cpanel cron tab.

I would imagine that the Last Succesful Run should be today?

So on the server, there is a bunch of WordPress installs and their cron jobs seem to be running. Going over the server with Support they can’t see anything wrong and that cron seems to be ok.

It looks like the cron jobs aren’t running from the directory where suitecrm is , but other places it’s ok.

I’ve checked the php.ini for that directory and made sure that “allow_url_fopen” and “allow_url_include” are enabled (some googling suggested this). But still no go.

Any idea why cron jobs wouldn’t be running on only this directory?

also the cron job is listed in the /var/cron log

Sep 15 09:00:01 ### CROND[20890]: (fccphil) CMD (cd /home/###/public_html/crm; php -f cron.php > /dev/null 2>&1)

Does that mean it ran?

I see you are using the default php handler in your PATH variable for cron
is this the same handler you are using for your crm instance?

some OS’s like CentOS provide very old handlers like 5.4 so control panels like plesk allow to install separate ones along side it.

what I’m getting at is the cron task may be using a php handler that does not work with SuiteCRM

We’ll suitecrm is running on php 7.3 and the os is CentOS 6.10 /cPanel/WHM

Which handler should I use?

It is the same handler in the crm instance

starting from 7.11.5 SuiteCRM supports PHP 7.3
otherwise the minimum version has to be 5.6
so we can rule that out.
unsure if you have the same functionality in cpanel but in plesk you have an option to send anything printed to stderr during the cron task in an email

you’ll have to drop the > /dev/null 2>&1 part on the end as this discards anything sent to stderr and stdout

replace

> /dev/null 2>&1

with something like


2> path_to_some_log_file.log

thanks so the job is now

cd /home/fccphil/public_html/crm; php -f cron.php > /dev/null 2> /var/log/crm.log

I created the crm.log file within the var/log directory?

or should it replace the “/dev/null” ?

Looks like none of the schedulers have the same last successful run date.

Do you have at least one job with “last ran successfully” at a recent time?

That would show that your cron set up is running fine; which basically means that Linux is doing its job of calling cron.php.

But then cron.php starts doing a bunch of jobs, and some of them might fail: so your problem with the Workflow job would be something else, and a matter for debugging or going through the logs (both)

Nope they all have the same last run date 2017-07

Ok. Try to find the exact location of the php executable. So you can add that to the cron command.


php -i | grep "'_'"

Suppose that gives “/usr/bin/php”

Then your cron command would become

cd /home/fccphil/public_html/crm; /usr/bin/php/php -f cron.php 2>/dev/null

or if you want the logging to the file, while you’re debugging this:

cd /home/fccphil/public_html/crm; /usr/bin/php/php -f cron.php  2>/var/log/crm.log

If I do

cd /home/fccphil/public_html/crm; /usr/bin/php/php -f cron.php 2>/var/log/crm.log

I get a “permission denied” error

Moved back to

cd /home/fccphil/public_html/crm; /usr/bin/php -f cron.php /dev/null 2>&1

I get an email with “cron.php is CLI only.”

What worked on my system is

cd /home/fccphil/public_html/crm; /usr/local/bin/php -f cron.php  2>/var/log/crm.log

All the workflows are now working and showing recent date for last successful run.

Thanks, everyone!

I’m glad you got it working! B-)

I suspect the “permission denied” was when the cron command generated an error, and it was trying to write to /var/log, which you probably don’t have access to.

You should just put it back to /dev/null, or if you really what to log it, maybe pick another directory that you are sure you have write access to.

1 Like