Domain Sync is not working properly

[EduPerea737]

Hi, I've set domain sync for 730 hours, It's like a month, but I see all days I'm recieving two mails, one of them, as usual: the cron job activities, and a second one, domain sync inform. Why? I want that domain sync is performed 1 time per month.

 

Thanks

[brian!]

15 hours ago, EduardoP737 said:

Hi, I've set domain sync for 730 hours, It's like a month, but I see all days I'm receiving two mails, one of them, as usual: the cron job activities, and a second one, domain sync inform. Why? I want that domain sync is performed 1 time per month.

it's worth remembering that domain sync only synchronises 50 domains at a time - so you're syncing 50 domains per month... if you have less than 50 domains in total, then that's fine... if you have 500, it's going to take 10 months to sync them all.

[EduPerea737]

Ohhh good to know that. By the way,  currently I have less than 50 domains, and domain sync is performing once a day, but I have set for 730 hours.

[WHMCS ChrisD]

@EduardoP737 are you running WHMCS v7.6?  In 7.6 the domain sync cron has been combined into the daily cron and no longer needs to de run separately.

 

[yggdrasil]

Brian is correctly. The domain sync runs in batches, which is a good thing as you don't want to abuse your registrar API limits or kill their servers. So take into account the number of domains before making the calculations when to run it, as you want them in sync at least once a month.

[yggdrasil]

On 8/19/2018 at 1:27 AM, WHMCS ChrisD said:

@EduardoP737 are you running WHMCS v7.6?  In 7.6 the domain sync cron has been combined into the daily cron and no longer needs to de run separately.

 

And this is bad. Some crons should not be consolidated. The domain sync is one of them and I certainly don't want to run this with my daily billing cron. How is this also going to work for someone with a massive amount of domains to sync?

[bear]

1 hour ago, yggdrasil said:

Brian is correctly. The domain sync runs in batches, which is a good thing as you don't want to abuse your registrar API limits or kill their servers. So take into account the number of domains before making the calculations when to run it, as you want them in sync at least once a month.

We have hundreds in there, so it's not going to work if it's the "once a day" cron. If it's going to run that every few minutes (based on the "every 5 minute" recommendation), it will upset the registrar, so how often within the main cron will that execute?

[brian!]

32 minutes ago, bear said:

We have hundreds in there, so it's not going to work if it's the "once a day" cron. If it's going to run that every few minutes (based on the "every 5 minute" recommendation), it will upset the registrar, so how often within the main cron will that execute?

default is every four hours - the quickest you can change it to is hourly - https://docs.whmcs.com/Automation_Settings#Domain_Sync_Settings

[WHMCS John]

Hi @yggdrasil,

It's been a long time since cron.php was a dumb script which would do everything each time it is touched.

These days it's more akin to a scheduler; each time it's run, it will determine which tasks need to be run based upon a number of factors including when a particular task was last completed and your automation settings. Some tasks need to be performed frequently - such as synchronizing the MailChimp - so are executed every 5 minutes. Others less frequently - such as invoicing - which is performed once per day,  or domain synchronisation @ every couple of hours.

In short this allows WHMCS to use a single cron job to execute various tasks at different times of the day based upon the requirements of the task and the configuration on the individual installation. It also simplifies the configuration and maintenance of WHMCS and registrar modules.

 

I hope that provides some clarification on why this change is not a bad thing.

[yggdrasil]

16 minutes ago, WHMCS John said:

Hi @yggdrasil,

It's been a long time since cron.php was a dumb script which would do everything each time it is touched.

These days it's more akin to a scheduler; each time it's run, it will determine which tasks need to be run based upon a number of factors including when a particular task was last completed and your automation settings. Some tasks need to be performed frequently - such as synchronizing the MailChimp - so are executed every 5 minutes. Others less frequently - such as invoicing - which is performed once per day,  or domain synchronisation @ every couple of hours.

In short this allows WHMCS to use a single cron job to execute various tasks at different times of the day based upon the requirements of the task and the configuration on the individual installation. It also simplifies the configuration and maintenance of WHMCS and registrar modules.

 

I hope that provides some clarification on why this change is not a bad thing.

As long as you let the individual tasks and batches to be configured separately like with a separated PHP cron file. So 1 single cron triggers WHMCS automation, but then WHMCS decides what tasks to run based on the settings for each task and timing. And the process tasks are isolated between each other (like a PHP file would). Example, I don't want one task timing out or going out of memory killing the whole automation and tasks inside affecting for example billing...

Let me make one example here:

Having 3 crons that run each one a PHP file separately is what just works, old but robust. If task 1 fails, it does not affect the others cron jobs. If one PHP crashes or dies, it still does not affect the others.

But if I just have 1 cron, that calls a PHP file which then calls all other PHP files that run the others tasks (with curl, command line or what ever). If that one process fails, all of them fail which is very bad. You are now putting all eggs in the same basket instead of leaving this to the the Linux cron. I still trust the old cron in the operating system more than a PHP file for critical tasks. If WHMCS is making all the checks and isolating the tasks, then that is fine. It depends on how properly the code is created in order to replace the normal Linux cron.

Edited August 20, 2018 by yggdrasil