upgraded from 778 to 786 got "cron.php is CLI only."

This post have 2 goals:
1 - give solution if you are experiencing the same problem
2 - to check if I should report a but on github…

after upgrading, I discovered that the group email where not fetched anymore…
looking at the php error log I found:
[15-Sep-2017 23:56:38 America/New_York] PHP Fatal error: Uncaught exception ‘Exception’ with message ‘cron.php is CLI only.’ in C:\inetpub\wwwroot\ve\include\utils.php:1687
Stack trace:
#0 C:\inetpub\wwwroot\ve\cron.php(49): sugar_die(‘cron.php is CLI…’)
#1 {main}
thrown in C:\inetpub\wwwroot\ve\include\utils.php on line 1687

looking for “cron.php is CLI.” I found some old references to this error with partial instructions… and I remembered
I saw that error a long time before… in 2014 when I migrated from sugar to suitecrm…
I still had my notes…
you need to open cron.php and comment the lines at around line 45
/*
$sapi_type = php_sapi_name();
if (substr($sapi_type, 0, 3) != ‘cli’) {
sugar_die(“cron.php is CLI only.”);
}
*/

Now my system runs ok

I checked and the function substr($sapi_type, 0, 3) return “cgi”
my cron job is configured as indicated:
"To Setup Windows Scheduler
In order to run the SuiteCRM schedulers, create a batch file to run using Windows Scheduled Tasks. The batch file should include the following commands:
cd C:\inetpub\wwwroot\ve
php.exe -f cron.php
"

Since my setup is Windows server running IIS and php 5.6 (and MSsql from another server) should I assume this is a bug in cron.php?

The reason that verification is there is to avoid letting people call cron.php from the Internet, which could cause weird behaviors, or it could be used intensively for a denial of service attack. If this risk seems negligible, it’s ok to remove the check, or to protect against it in a different way.

But according to the documentation php_sapi_name() should be giving you something different from “cgi” when called from the command-line. Maybe you can try calling it from the web browser and see if it says the same thing? Just make a small php file to print that and call it from the browser. Print all of it, not just the first 3 characters. Then call it from the command line with “php -f” and compare.

If SuiteCRM was to change the code here, I don’t know what could be used instead, other than simply removing the check altogether…

The best way to solve this without having to modify (in an upgrade unsafe way) the code would be to add a variable in config.php (and in admin) through which one can decide whether to be strict on the check or bypass it.

Having the check and nothing else is not such a good solution!

Depending on what values you get on your experiments, maybe we could keep the check, just make it adequate for more systems.

If we need to change it, your suggestion sounds good. We already have a “cron_allowed_users” in config.php, we could add a “cron_allowed_SAPI”.

ok got it…
I tested on 2 instances windows server 2008 and windows 10 (dev machine)
both gave the same result to echo php_sapi_name();

dos returned “cli”
web returned “cgi-fcgi”

I hope it will help …
Sege

Ok, that sounds right, but it doesn’t fit with what you got earlier.

Supposedly, your cron jobs are running from Scheduler, so they are using the DOS version, unless you have them invoking an URL in some way. But you said you were using “php -f”, that’s command-line.

So that should be giving “cli”, according to your more recent tests. If it was giving “cli” we wouldn’t be having this problem in the first place…

So… what’s going on?

Everytime I comment those lines out, and save successfully, it immediately gets overwritten by SuiteCRM???