The example below will run the WHMCS CRON and skip the update server usage routines. This is useful if your CRON takes abnormally long and possibly even aborts towards the end meaning you don’t have a clean log situation, or even worse, other important items completing.
php -q /home/domain/whmcs/crons/cron.php skip --UpdateServerUsage
At time you might want to do the opposite, perhaps to isolate the server usage update routines. In that case, do this:
php -q /home/domain/whmcs/crons/cron.php do --UpdateServerUsage
For more detailed troubleshooting, you can also run the UpdateServerUsage cron with -vvv, e.g.:
php -q /home/domain/whmcs/crons/cron.php do --UpdateServerUsage -vvv
For even more granular control, append a date statement before and after. Server Usage updates can take long, so this barometer could help you in the troubleshooting process:
date; php -q /home/domain/whmcs/crons/cron.php do --UpdateServerUsage -vvv; date
In our case, we had a server go offline, and then all our other servers stopped updating usage. So after a protracted troubleshooting session using many of the steps detailed above, we eventually found this in the system log file:
Server Usage Update Failed: Error code: 0. Error message: Curl error: [7] Failed to connect to xyz.host.example.com port 8443: No route to host. - Server ID: 26
We had to disassociate all server ID 26 with a new server, and thereafter were able to continue the server usage update script checks.
After even more protraced troubleshooting, we found this error, this time in the module log file:
Curl Error: 28 - Operation timed out after 300001 milliseconds with 0 bytes received
We use Virtualmin. The WHMCS module is set too low for the Perl scripts to execute. You can pay WHMCS $40 for an updated module with a larger timeout (e.g. 15 minutes), or you can contact us and we’ll try to explain this madness.