I would like to upgrade from 7.11.9 to 7.11.12 using the wizard.
The system check inside the wizard take endless and terminates with a blank screen. Timeout is set to 360sec in the php.ini, this should last I think.
In the log file no error is shown .
What can it be?
Delete directory cache/upgrades/temp and start again.
Thanks pgr,
but no change. The directory will be renewed when running the wizard, but it remains endless and stops with a white screen.
Ok
In Admin / Diagnostics / phpinfo you can get your effective values for php.ini settings. What do you see there for
Finally, what errors do you see in your logs at the time of the upgrade failure?
max-exec-time is local is 3600 (3thousand6hubdred) and master is 360 (3hundredsixty)
memory limit local is 300M master is 512M
**in the upgradewizaed.log I have following entries
Fri, 21 Feb 2020 15:00:29 +0000 [UpgradeWizard] - setting session variablesā¦
Fri, 21 Feb 2020 15:00:29 +0000 [UpgradeWizard] - -----------------------------------------------------------------------------
Fri, 21 Feb 2020 15:00:29 +0000 [UpgradeWizard] - Upgrade started. At start.php
Fri, 21 Feb 2020 15:00:29 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Fri, 21 Feb 2020 15:00:29 +0000 [UpgradeWizard] - finished!
Fri, 21 Feb 2020 15:00:29 +0000 [UpgradeWizard] - resetting $_SESSION
Fri, 21 Feb 2020 15:00:32 +0000 [UpgradeWizard] - setting session variablesā¦
Fri, 21 Feb 2020 15:00:32 +0000 [UpgradeWizard] - [At systemCheck.php]
Fri, 21 Feb 2020 15:00:32 +0000 [UpgradeWizard] - Starting file permission checkā¦
Fri, 21 Feb 2020 15:05:09 +0000 [UpgradeWizard] - setting session variablesā¦
Fri, 21 Feb 2020 15:05:09 +0000 [UpgradeWizard] - -----------------------------------------------------------------------------
Fri, 21 Feb 2020 15:05:09 +0000 [UpgradeWizard] - Upgrade started. At start.php
Fri, 21 Feb 2020 15:05:09 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Fri, 21 Feb 2020 15:05:09 +0000 [UpgradeWizard] - finished!
Fri, 21 Feb 2020 15:05:09 +0000 [UpgradeWizard] - resetting $_SESSION
in the suitecrm.log I have following entries (espocrm is the name of my correlated suitecrm database)
Fri Feb 21 15:05:40 2020 [3344][1][FATAL] Mysqli_query failed.
Fri Feb 21 15:05:40 2020 [3344][1][FATAL] Query Failed: DESCRIBE versions: MySQL error 1146: Table āespocrm.versionsā doesnāt exist
Fri Feb 21 15:05:40 2020 [3344][1][FATAL] Mysqli_query failed.
Fri Feb 21 15:05:40 2020 [3344][1][FATAL] Query Failed: SHOW INDEX FROM versions: MySQL error 1146: Table āespocrm.versionsā doesnāt exist
Fri Feb 21 15:05:40 2020 [3344][1][FATAL] Mysqli_query failed.
Fri Feb 21 15:05:40 2020 [3344][1][FATAL] Query Failed: select * from versions: MySQL error 1146: Table āespocrm.versionsā doesnāt exist
in the php_errors.log I have following entries
[21-Feb-2020 15:06:01 UTC] PHP Warning: include_once(/vardefs.php): failed to open stream: No such file or directory in ā¦ā¦\DiagnosticRun.php on line 660
[21-Feb-2020 15:06:01 UTC] PHP Warning: include_once(): Failed opening ā/vardefs.phpā for inclusion ā¦ā¦\DiagnosticRun.php on line 660
[21-Feb-2020 15:06:01 UTC] PHP Warning: include_once(/vardefs.php): failed to open stream: No such file or directory in ā¦.\DiagnosticRun.php on line 660
[21-Feb-2020 15:06:01 UTC] PHP Warning: include_once(): Failed opening ā/vardefs.phpā for inclusion ā¦\DiagnosticRun.php on line 660
[21-Feb-2020 15:06:02 UTC] PHP Warning: opendir(cache/diagnostic/a9b12f0d-3199-4781-a02f-5e4ff1d7f29e/diagnostic20200221-150537/,cache/diagnostic/a9b12f0d-3199-4781-a02f-5e4ff1d7f29e/diagnostic20200221-150537/): Cannot find file in . (code: 2) in ā¦.\DiagnosticRun.php on line 256
[21-Feb-2020 15:06:02 UTC] PHP Warning: opendir(cache/diagnostic/a9b12f0d-3199-4781-a02f-5e4ff1d7f29e/diagnostic20200221-150537/): failed to open dir: No such file or directory in ā¦\DiagnosticRun.php on line 256
I wonder, I have also following entry in the php_errors.log
[21-Feb-2020 15:05:04 UTC] PHP Fatal error: Maximum execution time of 180 seconds exceeded in ā¦ā¦\SuiteCRM\include\MVC\SugarApplication.php on line 624
This is not consistent with the information you gave above. One possible explanation is that maybe this is coming from a CRON job which runs under a different PHP (CLI).
If you try from the command-line
php -i
You can see the settings for that. Maybe you can grep it to get less lines:
php -i | grep -i 'max_\|_limit'
About this:
If you go in Admin / Repairs / Quick repair and rebuild and scroll down, does it mention any vardefs out of sync with database? If so, press the button to correct it.
No vardefs out of sync,
What about the rest? Does this still appear?
I managed to extend the time to 360sec and i got following error in the last try yesterday with a white screen result
PHP Fatal error: Maximum execution time of 360 seconds exceeded in ā¦ \SuiteCRM\include\MVC\SugarApplication.php on line 624
and following in upgradewizard.log before the white screen
Fri, 21 Feb 2020 22:10:37 +0000 [UpgradeWizard] - setting session variablesā¦
Fri, 21 Feb 2020 22:10:37 +0000 [UpgradeWizard] - -----------------------------------------------------------------------------
Fri, 21 Feb 2020 22:10:37 +0000 [UpgradeWizard] - Upgrade started. At start.php
Fri, 21 Feb 2020 22:10:37 +0000 [UpgradeWizard] - at unlinkUWTempFiles()
Fri, 21 Feb 2020 22:10:37 +0000 [UpgradeWizard] - finished!
Fri, 21 Feb 2020 22:10:37 +0000 [UpgradeWizard] - resetting $_SESSION
Today first try the same white screen after 6 minutes but no entries in php_errors, suitecrm.log or upgradewizard.log
Is it still failing in the original āsystem checkā screeen, or later?
Donāt forget to keep deleting directory cache/upgrades/temp on each attempt.
You can increase over 6 minutes to see if it finishes. But it is strange why itās taking so long. This delay is dependent on the number of files (not file size) in your installation, and the general disk slowness of your system. I donāt know if there could be any reason why you have a huge number of files?
Yes still failing in the original system check, it doesnt go further. Also after re deleting the upgrade cache.
Any other way to update suitecrm without the wizard?
Have a look at this workaround
Seems that this worked for me. In Admin/Info it shows me 7.11.12 and sugar 6.5.25-344.
But I am not able to open the upgradeWizard in Admin anymore, it ends with a blank screen. No entries in the errors logs except in php_errors
[22-Feb-2020 16:41:15 UTC] PHP Warning: dir(ā¦SuiteCRM/cache/upgrades/temp/D982.tmp/scripts/files_to_add_post/themes/): cannot find file (code: 2) in ā¦\CRM\SuiteCRM\include\dir_inc.php on line 57
[22-Feb-2020 16:41:15 UTC] PHP Warning: ā¦SuiteCRM/cache/upgrades/temp/D982.tmp/scripts/files_to_add_post/themes/): failed to open dir: No such file or directory in ā¦CRM\SuiteCRM\include\dir_inc.php on line 57
I had the same problem and used this solution you suggested in an older thread where you just had the vendor folder added. That got me past the check. I ended up having to do a lot of things to get mine to work. This has happened to me on a previous update as well so maybe some of these tips might help.
First, I repaired and optimized my DB just to make sure it was working as fast as possible. Then I noticed there was a mismatch in the config.php for the database connection and database type. I had utf8_general in config.php but the db was utf8_unicode. Fixed that and it seemed to get past a few DB connection timeout issues. Not sure why that would make much difference. A unicode table / db should be able to take a general connection?
Iām on a shared hosting environment, but it is NOT underpowered. On top of that, they recently did a planned hardware upgrade to SSD / flash drives. However, there are occasional performance issues during business hours for DB updates and file reads. So, I did my updates either late at night or on Saturday morning when the host system was relatively quiet. Things didnāt start working well until I turned off all the error logging and limited some basic system checks.
I also noticed that when I would do a quick repair and rebuild after each step it seemed to create more problems than it solved. I donāt know, does that reset some possible changes or pending changes?
I took a suggestion you mentioned in a previous post and rather than deleting the whole cache / upgrade / temp folder after each step, I just deleted all of the folders under there except the newest one. That helped too.
By repeating the process, and manually deleting the old cache folders, I eventually got through it. But I didnāt use your updated systemCheck.php with the cache and upload directory skips you have listed here. Should those be included permanently in the systemCheck file?
Thanks Woodb01, I could go one step further by deleting all older dir in the cache/upgrade/temp/ folder and leaving the newest. But upgrade system check still running endless, also after adding .well-knownā, ā.svnā, ā.gitā, ācacheā, āuploadā, in the systemcheck.php. Currently I have the system updated to 7,11,12 but I am already worried for the next update.
To both of you (@woodb01) if you want more specific answers you should open your own thread), these upgrade issues have been worked on, but they only take effect on the next upgrade cycle. This upgrade brings upgrade-code improvements, but you will only see them active in the next upgrade.
Thank you for your help on this. My post was not a criticism, only to provide what worked for me. I realize re-writing a lot of the processing around iterate, vs existing file array builds is a lot of work with significant testing required.
I look forward to the update(s) when it becomes available.