Automated database backup not sent after update to v7.3.0

[mustardman]

Anyone else?  I have updated the cron files in the custom cron location.  The activity log shows the backup job firing and the temp file being successfully created.  However, it does not go any further than that.  No errors in activity log.  The temp file is still sitting there in /tmp.   I never got the backup emailed to me or sent to the FTP server like it was doing before the update.  Pressing the test connection button in `Other > Database Backups` successfully saves a `testfile.txt` file on the FTP server and indicates success in the GUI so WHMCS can definitely connect to the FTP server.

WHMCS made some changes to Automatic Backups in v7.3.0 which leads me to suspect it's not just my install.

https://docs.whmcs.com/Backups

Is there any way to manually run the daily backup for troubleshooting?  I can manually download a backup at `Utilities > System > Database Status` but that is not what I want.  I want to manually run the automatic backup.

Edited October 8, 2017 by mustardman

[mustardman]

I figured out how to run the daily backup manually from the following link.

https://docs.whmcs.com/Crons#Option_Flags

So for anyone else wonder, the command would be:
 

php /root_folder/crons/cron.php do --DatabaseBackup

Which works.  So for some reason it fails when running the cron.php automatically on the daily job.  Maybe I needed to press that Test Connection button and have it verify that first? The manual says that verification is only needed for cPanel which I am not using.  Will have to wait and see if it works tomorrow.

Edited October 8, 2017 by mustardman

[WHMCS ChrisD]

Hi @mustardman

How big is your Database Backup?  It could be that your cron is hitting the PHP Memory or Timeout Limits when running as part of the main cron.

[mustardman]

17 hours ago, WHMCS ChrisD said:

Hi @mustardman

How big is your Database Backup?  It could be that your cron is hitting the PHP Memory or Timeout Limits when running as part of the main cron.

Compressed, the backup is only about 12MB.  I have my PHP timeouts set to 2 minutes and the Memory set to 128MB as recommended.  Manual backups from GUI work fine.  Manual backup using cron job works fine.  The automatic cron backups worked fine with the exact same backup and php timeout settings when using WHMCS v6.

Edited October 9, 2017 by mustardman

[mustardman]

It failed again today.

[mustardman]

2 hours ago, mustardman said:

It failed again today.

I did find one problem related to the higher php version requirement of v7.  As a result I have multiple versions of php installed with multiple php.ini files.  The max_execution_time for the php7.0.ini was configured with max_execution_time=30.  So I increased that to 120 and will wait and see what happens tomorrow. 

[brian!]

4 hours ago, mustardman said:

As a result I have multiple versions of php installed with multiple php.ini files. 

this rings a bell as I can recall another thread mentioning that (though I can't find it!)... hopefully the new setting solves the issue.

[mustardman]

It is still failing.  I think it might be a bug in WHMCS v7.3.0.   It generates the backup but makes no attempt to send it to email or FTP.  There are no errors in any of the logs.

I can work around it for now by creating a separate cron job.

Edited October 10, 2017 by mustardman

[mustardman]

I cranked up all my timeouts and max memory settings and it's still failing.  Pretty sure this is a bug.

[WHMCS John]

Hi,

I would be keen if any other users are experiencing this same behaviour to report it here. If it were a bug I'd expect to see other reports of the problematic behaviour.

Please temporarily enable the Setup > General Settings > Other tab > Display Errors option, then  adjust your cron to:

php -q /path/to/crons/cron.php -vvv >> /path/to/crons/crondebug.txt

Replace /path/to/crons/ with the actual path to your crons directory.

Next time the problem occurs, please share the contents of the crondebug.txt file.

[mustardman]

For anyone else having this problem.  It appears to be related to /vendor/phpmailer/phpmailer/class.smtp.php.   It appears to be ignoring php.ini `memory_limit=256M` and using the PHP default of 128M even though WHMCS and phpinfo();  show that php is max memory is set to 256M and there is still plenty of spare physical memory.

I figured it out by running the cron without the -q or the >/dev/null 2>&1 which then caused cron to send the out of memory error message to root.

The error occurs on line 655

$lines = explode("\n", str_replace(array("\r\n", "\r"), "\n", $msg_data));

The workaround is to add the following line just before line 655

ini_set('memory_limit','256M');

That will get overwritten every time WHMCS updates that file so it's just a workaround.

 

Edited October 14, 2017 by mustardman

[mustardman]

I finally got to the bottom of this.  My environment uses different php.ini files depending on whether php is run from Apache or from CLI.

WHMCS uses the php.ini file used by Apache.  However, phpmailer (included with WHMCS) apparently uses the php.ini file used when php is run from CLI.  When I change the max memory in the php.ini file that the CLI environment uses then phpmailer uses that memory limit.

You can check the php.ini file used by CLI by running the following command 

php --ini

 

Edited October 14, 2017 by mustardman