Interesting cron ouput when testing cron job

Reposted. I had this in the wrong thread. Re-posted it here where it belongs.

Also keep this in mind. If you have a 3'rd party module that is getting errors during it's cron run, than chances are that cron job did not complete.

All cron jobs have a reason for being there. Cheetah for example has jobs to process videos, cleanup the database, send nightly reports, ect. So if a modules cron job is failing, whatever task that job was intended to do is not getting done. So even if the module appears to be fine from the front end, it is actually not properly working. So hiding the errors is not a solution because that modules cron job is not completing and chances are any cron job after that one also may not be processing either.

This is a issue that will become more common when php 8 starts getting more use.

Unfortunately i cannot do anything about the 3'rd party modules.

However this will still be a issue i will need to deal with in cheetah. I will need to make sure all of cheetahs cron jobs are run before 3'rd party modules including cheetah modules that were installed after the third party modules. Reason is because if a cron job fails, the rest of the jobs after it will not run either. So i will have to deal with that somehow.

Yes, cron will run under the CLI (command line interface) of PHP.  If you can locate the CLI of php 7.4, then you can specify in the cron job which php to run for the particular cron job.  Each cron job can be ran under a different PHP version.  Also, the CLI parameters can be different than the PHP parameters you are using to run website PHP scripts.

I struck the same problem with a few converted modules from Modzzz. I was receiving 100 error emails a day from the panel and the problem persisted until I read this thread. When I added the PHP version code to my Cron job, I discovered that Cron was running on PHP 8 even though my entire server is set for PHP 7.4.

I'm using the Hestia CP and it seems that it runs under PHP 8 and you can't change it.  Fortunately there's a button on the Cron page which states "Turn Off Notifications". By clicking that button, the emails instantly stopped. As there were no other errors, I decided I could live without those 100 plus daily reminders.

I tried several times to change the php cli version since there are multiple sites on the server that may have issues with php 8 cli.  However, I ran into problems each time.  I wish I hadn't installed php 8.  The solution for now was to simply direct the cron job to use php 7.4.26; of course I had to find the proper path.  I may have to edit the other site's cron job.  It is all good now.  Just the things you run into as a sys admin.

Yes. I expected that.

I added: echo 'Current PHP version: ' . phpversion();

to the cron.php file.

The results was:

Current PHP version: 8.0.13

When you mentioned testing Cheetah on php 8, I installed php 8 on the server and it screwed up some things.  I thought I had cleaned it all up.  The site is running on 7.4.26 but the cron.php file runs on php 8.  A side note on this is that I have found out that third party Dolphin modules may need some work to run on php 8.

You can ignore my last post on that. on and off are also suppose to work because the ini_get function returns 0 if set to off and 1 if set to on. True and false are also suppose to work as well.

I think i was thinking 0 and 1 because i ran into a issue awhile back when testing php versions and found that in some versions of php a off setting returns a empty string and was messing up the script that checks the values.

Yea. Something is screwy.

I am guessing for some reason the site is using a mishmash of different PHP versions. That error above would be expected if PHP 8 is running because PHP 8 is much stricter with declarations which must match in PHP 8.

So perhaps the site is running one version of PHP and the CLI version is PHP 8.

In any case, something is definitely wacked.

The normal result for running cron.php in the backend is "No Output Generated."  Not this stuff I am seeing.  Something is broken about the site.  Not sure how long this has been in place.  Just noticed it today because video uploads were not processing.

I moved the site to php 7.4 and still get the same thing from running the cron job.

I just checked the Cheetah 1.2 beta site and it works normally.  Mmmmmmmmmmm

I removed the error check from the header.inc.php file and then ran the cron job from the control panel again and got a new error:

PHP Fatal error:  Declaration of ChListingModule::_browseMy(&$aProfile) must be compatible with ChWsbTwigModule::_browseMy(&$aProfile, $sTitle = null) in /home/DEPRECATED/public_html/modules/modzzz/listing/classes/ChListingModule.php on line 3129

Fatal error: Declaration of ChListingModule::_browseMy(&$aProfile) must be compatible with ChWsbTwigModule::_browseMy(&$aProfile, $sTitle = null) in /home/DEPRECATED/public_html/modules/modzzz/listing/classes/ChListingModule.php on line 3129

Something is not right here.

By the way, you need to remove the one about short open tags as well since short open tags have been removed.

Yes, PHP manual does say boolean; I have been using on and off forever;   I guess I was basing it off of the allow_url_fopen which is on and off.  Default is 0 so I guess the off was defaulting to 0.  Therefore, it was still working as intended. 😀.  This site says to set it to 'off'; maybe I saw it somewhere as on and off ; https://www.acunetix.com/vulnerabilities/web/php-allow_url_include-enabled/  Yes, I shelled in and checked to see which php.ini the command line was using and of course host tools in the admin told me the php.ini for the site.

Never seen this triggered before; I am just going to remove it and see if the cron job works.  I am going to set the site back to php 7.4 when I have time.  Things got sort of screwy when I installed php 8 to test Cheetah on php 8.  

Temporally edit periodic\cron.php

Right after this line. $aPathInfo = pathinfo(__FILE__);

Add this.

echo php_ini_loaded_file();

Then run from your control panel again. That line should tell you which php.ini file it's using.

Note: allow_url_include is a bool value. Should be a 0 or 1 and not on or off.

Also note. You can just remove the following line from your sites inc/header.inc.php

    $aErrors[] = ((int)ini_get('allow_url_include') == 0) ? '' : '<font color="red">allow_url_include is On (warning, you should have this param in the Off state, or your site will be unsafe)</font>';

I need to remove that from future cheetah versions anyway because that option has been depreciated as of php version 7.4.0

My videos were not moving from Pending Processing.  So I went in my control panel to run the cron job.  I got the following output:

allow_url_include is On (warning, you should have this param in the Off state, or your site will be unsafe)
Please go to the Cheetah Troubleshooter  and solve the problem. 

I have checked all of the php.ini configurations and all of them have allow_url_include turned off.  I also checked the command line php.ini file and it was off.  I have never seen this output above when running the cron job from the control panel.

To see if the cron.php was not being ran by the system, I disabled the .htaccess file and then manually ran the cron.php from the browser URL and it worked and the videos were processed.