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, 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âŚ