wrong cron timing

[djpete]

 

server time is right

cron settings in whmcs is set to 8am daily

settings for cpanel are 

*/5 * * * *

BUT I still don't get reports at 8am. They come at night around 10pm

Any tips appreciated

[WHMCS Alex]

Hi @djpete,

The detail under the “Timezone the cron operates under” section of the following documentation should help you resolve this: https://docs.whmcs.com/Changing_Timezone

[djpete]

thanks but already done that and time is set right in whm

I will ask tech on my server to have a look a second time...

😞

[yggdrasil]

19 hours ago, djpete said:

thanks but already done that and time is set right in whm

I will ask tech on my server to have a look a second time...

😞

I had a similar problem and the reason is most likely the following. While I don't use cPanel I do have more than one PHP version installed since CentOS or any other RHEL based Linxu distro (which is also what you probably run with cPanel) comes with an older PHP version by default. If you are running PHP 7 on a cPanel server, then you are not using the one that comes with the operating system, that is for sure.

There is the PHP that is the default installed on in your server and then there is the PHP that you probably configured to run with WHMCS. A custom one.

But here comes the issue. Cron jobs by default use the system default PHP version. It's not using your WHMCS PHP 7 version. It's using the PHP that runs in your server and that probably has a different timezone. This drives some people crazy as they keep changing the timezone in their PHP settings but they don't seem to take effect, because the crons or any script that is runs on the server and not trough the web server is not using the same PHP.

Check this first. If you have indeed a different PHP configuration for your domain which is what WHMCS is using, not the same as your server, then you have 2 options:

1. Change the timezone on php.ini for the server PHP settings in your server to match your time zone. 

2. Add an extra line to your cron task with the parameters (path) for your custom PHP version, that way the cron will execute the scripts with that specific PHP version instead of the default one from the server.

Your server admin will know what I'm talking about if you have more than one PHP version installed.

[WHMCS Alex]

Hello,

If you are having issues getting to the bottom of it, my personal recommendation would be to specify a date.timezone value in the cron command itself. The reason for this is then you can be absolutely sure it's executing under the correct timezone, and it saves having to investigate any difference between the timezone your php-cli is using vs what is set for this in the PHP configuration applied to web pages like WHMCS. Below is an example of running the cron.php script under the Europe/London timezone:

php -d "date.timezone=Europe/London" -q /path/to/crons/cron.php

 

[yggdrasil]

3 minutes ago, WHMCS Alex said:

Hello,

If you are having issues getting to the bottom of it, my personal recommendation would be to specify a date.timezone value in the cron command itself. The reason for this is then you can be absolutely sure it's executing under the correct timezone, and it saves having to investigate any difference between the timezone your php-cli is using vs what is set for this in the PHP configuration applied to web pages like WHMCS. Below is an example of running the cron.php script under the Europe/London timezone:

php -d "date.timezone=Europe/London" -q /path/to/crons/cron.php

Seem overcomplicated because even if he does that, running an old PHP version will cause him other issues and weird bugs. I know it did with my case, example SSL checks not working and some other strange bugs because when he checks on the admin side it works fine but the cron it works differently if using an older PHP version.

I would rather advise him to look at his PHP path (from the php info on the admin side) and then modify the crons to include that path.

Example.

If his PHP is located in:

/opt/rh/rh-php73/root/usr/bin/php

Modify all the crons to include:

/opt/rh/rh-php73/root/usr/bin/php -q /path/to/crons/cron.php

Then he will be executing every cron with the same PHP version he is running WHMCS. Problem solved!

[WHMCS Alex]

Hello @yggdrasil,

Thanks for your response!

Quote

Seem overcomplicated because even if he does that, running an old PHP version will cause him other issues and weird bugs.

Where the cron is completing at the wrong time but otherwise with no issue (indicated here by the report being emailed to administrators), the most straight forward resolution would be adjusting the cron command to specify a date.timezone value, per my suggestion.

If there are further issues with the cron, such as  the PHP configuration used by the CLI being a different as detailed HERE, then specifying the path to the PHP binary within the cron command as you suggest, is also a good step to take that likely does not require the server administrators help. 

[djpete]

Oh thanks all for the in depth help.

I have now added a php.ini file with date.timezone=Australia/Melbourne

Will see if that fixes the issue as the datacentre said "The current
> timezone in php.info is:
> date.timezone => AEST => AEST"

 

so see what this does.

I will update tomorrow. Hopefully it will fire at 8am as I want.

 

I hate IT lol

Edited July 11, 2020 by djpete

[djpete]

....even though it was set to Australia/Melbourne on my server

Edited July 11, 2020 by djpete

[djpete]

still coming at 6pm!
Arrrr

[yggdrasil]

8 hours ago, djpete said:

....even though it was set to Australia/Melbourne on my server

As I said above, that solution is a dirty fix that will probably not work.

1. Edit your timezone in your php.ini file (google this for instructions)

2. Edit all your crons and include your PHP path as with the example I posted.

There is no reason to pass the time manually on calls when you probably don't need to change the timezone ever. Its a one time fix, configure PHP with your time and make sure the cron jobs are using your proper PHP version.

It should take 20 minutes to fix this for anyone that knows a bit around servers and configurations. Ask your hosting company for help or server administrator. Its a simple fix.

Enjoy!

Edited July 11, 2020 by yggdrasil

[WHMCS Alex]

Hello @djpete,

Setting the date.timesone value in the cron command itself, as I suggested, would ensure cron.php is executed under the timezone you require. Unless I misunderstood, that was not something you tried, instead, you added a php.ini to your WHMCS directory with a date.timezone set, which would not apply to the command line interface where cron.php executes.

I would advise modifying the cron command as per my suggestion above, or, reach out to your server administrator to investigate and resolve the matter for you.

Hope this helps. 

[djpete]

thanks again. datacentre not replying so will give it a go

 

Current path with tail end dropped off for security...

/usr/bin/php -q /home/accountname/public_html/path to cron

 

Are you able to modify this section of the address and I will add the end bit and try..

Greatly appreciated!

[djpete]

and does that mean since i have php set to inherit I will have to adjust this cron to reflect the php version after each php auto update. Wow what a complete pain if so..

[djpete]

using PHP 7.3 

[djpete]

ok added this

/usr/bin/php -d "date.timezone=Australia/Melbourne"-q /home/account name/public_html/folder name/crons/cron.php

[djpete]

this shows in whmcs as an example though...

Confused again

/opt/cpanel/ea-php73/root/usr/bin/php -q /home/account name/public_html/folder name/crons/cron.php

[djpete]

and still coming at 6pm

Maybe I should open a support ticket with WHMCS?

Edited July 12, 2020 by djpete

[WHMCS Alex]

Hello @djpete,

I picked up the ticket you opened and implemented my suggested resolution. After doing so, I confirmed the reported time by cron.php now matched the time shown within the WHMCS admin dashboard (indicating they are operating under the timezone now).

I would expect the cron to complete and email you the report at the expected time of 8am now.

I hope this helps.